-
Notifications
You must be signed in to change notification settings - Fork 5.4k
Experimental: index
, index_assign
, and nested storage maps
#4331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
3945de9
to
3b94da2
Compare
get_handle
to help implementing nested storage mapsget_handle
to help implementing nested storage maps
648b2f0
to
be85a10
Compare
893905a
to
c7a2e45
Compare
get_handle
to help implementing nested storage mapsindex
, index_assign
, and nested storage maps
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit weary of forging ahead with specialized indexing for the storage types while we don't have a clear idea of how we'll approach the Index
trait just yet.
E.g. these implementations take self: StorageHandle<Self>
, which would likely differ from the actual method signature we are likely to want on an Index
trait. If we're to end up allowing specialized indexing on storage types that differs from an Index trait behaviour but both use the same []
syntax sugar, I'm worried we'll just cause more confusion for devs?
One alternative could be similar to the suggestion mentioned here, and allow for implementing the Index
trait for StorageHandle<StorageMap<K, V>>
(rather than using self type ascription). E.g.
trait Index<Ix> {
type Output;
fn index(self, ix: Ix) -> Self::Output;
}
impl<K, V> Index<K> for StorageHandle<StorageMap<K, V>> {
type Output = StorageHandle<V>;
fn index(self, ix: K) -> Self::Output {
self.get(ix)
}
}
This would not incur the same issues w.r.t. orphan rules as mentioned at the linked comment as the Index
trait would likely be declared in the same library that provides the implementation (i.e. sway-lib-std).
* Added `try_read()` that behaves like `read` but returns an `Option` * Changed `get` in `StorageMap` to return a `StorageHandle` instead of the value directly.
985cde0
to
342094c
Compare
- Remove support for type ascription on `self` for now - Instead, we now do `impl StorageKey<StorageMap<K, V>>` which seems to work just as well
342094c
to
bb4d899
Compare
e40d42e
to
4933108
Compare
… nested maps using both `get/insert` and the `[]` operator
7bb31af
to
9dfa0fb
Compare
1e421cd
to
4a90079
Compare
Description
Introduce
index
andindex_assign
toStorageMap
and showcase how storage maps and nested storage maps could look like with and without the[]
operator. These two methods should really be part of traitsIndex
andIndexAssign
but we're not ready to implement those yet because we do not have associated types for traits yet.In any case, de-sugaring to
index
was implemented but de-sugaring toindex_assign
needed some work in how reassignments are handled.Note that
IndexAssign
is inspired by rust-lang/rfcs#1129. This is probably the best we can do given that we don't want references in the language just yet (and probably ever).Checklist
Breaking*
orNew Feature
labels where relevant.