Allow to name the generic for storages in #[pallet::storage]

[gui1117]

This PR make the macro handle to give named generics.

So you can declare like this:

#[pallet::storage]
pub(super) type MyStorage<T> = StorageMap<Hasher = Blake2_128Concat, Key = u32, Value = u32>;

#[pallet::storage]
pub(super) type MyStorage<T> = StorageDoubleMap<
    Hasher1 = Blake2_128Concat, 
    Key1 = u32, 
    Hasher2 = Blake2_128Concat, 
    Key2 = u32, 
    Value = u32,
    QueryKind = ValueQuery
>;

NOTE: no need to write Prefix = _,

NOTE: no need to declare them in order, and no need to declare all of them. For instance if user want to set OnEmpty generic, it can avoid declaring QueryKind, the default query kind will be expanded by the macro

context

This is motivated from feedback about readability.
This is also motivated in order to add yet another generic for storages: MaxValues which would tell the storage the expected number of max values #8729 #8735

[shawntabrizi]

Why are we allowed to drop this here: NOTE: no need to write Prefix = _,

Obviously it is preferred to not have _ in the front, but why not in the original syntax too?

[gui1117]

Actually the exact specification should be discussed, this is my thoughts:

• We do not mix both declaration (no partly named, partly unnamed): this is because in the long term I expect ppl to use named one, and mixing would be more confusing than helpful. But we could do something like python named argument which allows to specify unnamed and named ones.

• For named arguments, only the mandatory ones must be specified, all the generic which have a default in the struct (e.g. OnEmpty=GetDefault) can be omit. Because a user could specify OnEmpty but not QueryKind, that means the macro have to expand QueryKind with the correct default type in order to be able to set the OnEmpty as given by the user.
  The main reason for this is so that people can later specify MaxValues without having to specify OnEmpty.
  Considering this I thought Prefix can be considered as "non mandatory" and the macro will always expand this generic correctly. I feel because we introduce custom handling of arguments it makes sense to drop Prefix = _ as people can expect the macro to handle stuff.

• Also I allowed named argument to be specified in any order but this is probably personal sensitivity and I can see argument for fix order.

[cla-bot-2021]

@thiolliere No commands could be detected from your comment.

[shawntabrizi]

allowed named argument to be specified in any order

Would this be allowed for a regular rust type?

[bkchr]

allowed named argument to be specified in any order

Would this be allowed for a regular rust type?

When you for example have some trait and want to set the associated types in a where bound, you can also give them in any order.

Requiring an order for stuff that is uniquely named is weird and just complicates the whole process again.

[gui1117]

the other idea which I don't prefer:
we can make argument generally more named by wrapping them in some types, also grouping them, something like:

type Foo<T> = StorageMap<_, Key<Twox128Concat, u32>, ValueNonOption<u32, OnEmpty3U32>, MaxValues<ConstU32<300>>>;

type Foo2<T> = StorageMap<_, Key<Twox128Concat, u32>, ValueNonOption<u32>, MaxValues<ConstU32<300>>>;

type Foo3<T> = StorageMap<_, Key<Twox128Concat, u32>, ValueOption<u32>, MaxValues<ConstU32<300>>>;

But I think named generic is more understandable than rust wrapper which add one layer of complexity in the types.

[shawntabrizi]

yeah i agree, what exists now is better

[bkchr]

Some nitpicks, otherwise looks good

[bkchr]

Not such a good diagnostic. Can we not use the correct span here?

[gui1117]

yes we can point to the type alias instead of the storage attribute.

note that this not due to this PR, it is because we use the span of the attribute when expanding the storage metadata and getter. I think we can do in a follow-up i'll do an issue and look at it.

[gui1117]

I tried to improve a bit in this draft #8850

[bkchr]

Perfect! :)

[bkchr]

bot merge

[ghost]

Trying merge.