-
Notifications
You must be signed in to change notification settings - Fork 2.6k
BoundedVec + Shims for Append/DecodeLength #8556
Conversation
frame/support/src/storage/mod.rs
Outdated
impl<T: ValueType, S: Get<usize>, V: generator::StorageValue<BoundedVec<T, S>>> TryAppend<T, S> | ||
for V | ||
{ | ||
fn try_append<LikeT: EncodeLike<T>>(item: LikeT) -> Result<(), ()> { |
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.
yeah, though eventually we'll probably want this to become a DispatchError
to avoid a lot of .map_err(|()| Error::<T>::ItemOverflow)
s.
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.
Not sure which variant it should be? Other
or a new (general)Overflow
would be okay, but the benefit of .map_err(|()| Error::<T>::ItemOverflow)
is actually that we know from which pallet it is coming from.
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.
cool addition!
frame/support/src/storage/mod.rs
Outdated
/// As the name suggests, the length of the queue is always bounded. All internal operations ensure | ||
/// this bound is respected. | ||
#[derive(Encode, Decode, crate::DefaultNoBound, crate::CloneNoBound, crate::RuntimeDebugNoBound)] | ||
pub struct BoundedVec<T: Value, S: Get<u32>>(Vec<T>, sp_std::marker::PhantomData<S>); |
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 guess that this is using a type number with Get<u32>
instead of a const generic because we don't want to raise the min supported rust version to 1.51?
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.
Actually it probably can, I just didn't think about it :D Will try
because we don't want to raise the min supported rust version to 1.51?
I am pretty sure we always require latest stable version and don't care much about older versions.
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.
errr -- no.
I don't think we can make this configurable to the end-user, as it is now, with const generics. See how it is done in #8580.
We can, only if we swap things like type MaxProposal: Get<_>
for const MAX_PROPOSAL: _
.
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.
Right, ok. I think that in the future it may be worth a large-scale refactor to use actual consts and const generics instead of faking it with type parameters, but that may have to wait for Frame 3.0.
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.
We would already have switched to associated consts if it would be beneficial. The main advantage of using the trait is that we are much more flexible in tests. Overwriting constants would be a mess. Now we can just use thread local variables to overwrite the values.
And than there are also test runtimes where the trait enables us to read variables from the storage and thus, make it really flexible.
We would loose all this flexibility when using const generics.
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.
yeah, tests are also an issue with regard to const. Either of you know what kind of shenanigans we'd need to override consts? if possible at all?
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.
We would need to make tests more generic, add new traits that provide the consts we want to override and implement X times, everytime with the const value we want. You see where this is going. This would not be easy and would just require tons of boilerplate without any advantage.
frame/support/src/storage/mod.rs
Outdated
/// Storage value that is *maybe* capable of [`StorageAppend`]. | ||
pub trait TryAppendValue<T: Value, S: Get<u32>> { | ||
fn try_append<LikeT: EncodeLike<T>>(item: LikeT) -> Result<(), ()>; | ||
} |
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.
why not creating TryStorageappend
trait, and create the function fn try_append
directly in StorageMap, StorageValue and StorageDoubleMap traits, with a where clause, similarly to fn append
.
Also if you want those function to be accessible on storages without having to import trait in scope, then it should also be written in "frame/support/src/storage/types/value.rs"
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.
Sounds good, so far I tried to NOT add anything extra to the bast traits StorageValue
and generator::StorageValue
, but yeah this will enable us to not need to import the extra trait everywhere.
having But I would like that we implement (Apart from that we can improve to not require the value to be Eq, PartialEq, and Default, but this can be done later when needed.) But otherwise it looks good to me |
* Example with balances * Fix tests * Make it indexable * fix * Fix tests * fix test * Fix collective as well * Fix test
Co-authored-by: Peter Goodspeed-Niklaus <coriolinus@users.noreply.github.com>
For now I kept them in separate traits that get a blanket implementation. If and when
Done.
Also done.
|
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.
looks good to me
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
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.
some nits
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.
looks like a great start :)
Need an issue to migrate existing vecs into the boundedvec
bot merge |
Waiting for commit status. |
cc @shawntabrizi @gavofyork