Make storage give the expected maximum number of values (for PoV)

[gui1117]

related #8719, paritytech/polkadot-sdk#398

We want storages to give the maximum number of values.

One idea is to have user giving it to the macro for each storages and the macro would make use of it to generate the storage description needed for PoV computation.
it can look like this:

#[pallet::storage(max_values = 300)]
type MyStorage = StorageMap<_, Twox128Concat, u32, u32>;

But actually we could modify storage types so they implement the bound themself. (the idea is that the macro generate less stuff, and instead it is just regular rust code).
For this we would modify StorageMap and add a const generic in 2nd position.

pub struct StorageMap<Prefix, MaxValues, Hasher, Key, Value, QueryKind=OptionQuery, OnEmpty=GetDefault>(
	core::marker::PhantomData<(Prefix, MaxValues, Hasher, Key, Value, QueryKind, OnEmpty)>
);
// NOTE: we use a generic here for MaxValue and not a const generic because we might want to make it 
// configurable.
// But at some point using `const MaxValue: u32` could be enough.

pub struct ConstU32<const T: u32>;
impl<const T: u32> Get<u32> for ConstU32<T> {
	fn get() -> u32 {
		T
	}
}

#[pallet::storage]
type MyStorage = StorageMap<_, ConstU32<300>, Twox128Concat, u32, u32>;

I'm not sure what is best yet another generic which is not named and make the list quite long. Or an attribute but this bring more macro magic.

For now I'll go for the new attribute

[shawntabrizi]

@thiolliere I prefer the attribute as it feels to me more clear to read.

Also for developer experience, we may allow users to omit this setting for non-production chains.

[coriolinus]

FWIW I also prefer the attribute. I think that pallet declarations are already sufficiently magical that an additional bit of macro use doesn't substantially affect the weirdness budget.

[gui1117]

FWIW I also prefer the attribute. I think that pallet declarations are already sufficiently magical that an additional bit of macro use doesn't substantially affect the weirdness budget.

I would argue the second proposal with an additional generic is less magical as it uses no macro.
But I understand your point.

[bkchr]

While I know that the code was written in a way that it is as much as possible standard Rust, I have to emit, that seeing:

#[pallet::storage]
type MyStorage = StorageMap<_, ConstU32<300>, Twox128Concat, u32, u32>;

Doesn't really tell me anything. I have to check StorageMap and see what these values mean.

I think we maybe should support some extra syntax:

#[pallet::storage]
type MyStorage = StorageMap<Hash = Twox128Concat, Key = u32, Value = u32, MaxValue = 300>;

While MaxValue could be optional like the attribute. However, the default Rust syntax as it it used currently, could stay allowed as well.

Adding now an extra attribute, while the rest is more or less on the type system level makes it more weird IMHO. Then we could already have done this from the beginning and put everything into the attribute.

[gui1117]

ok going to optionally named generic is good to me.

Then we add another optional extra generic for storage types and people can specify without having to specify other optional generics. and without confusion of too many params.