Vision: #[pallet::constant(non_volatile)]

[kianenigma]

This came up in a discussion with @gpestana recently. There are a number of Get<_> associated types in a runtime that should not really change after being once set. If they are to be changed, we probably need a migration. For example, all of the type MaxSomething: Get<u32> might imply a migration if we reduce them.

The idea is to mark these with a special flag that says they should not change. I am not sure if non_volatile is a good word here. Then, in construct_runtime!, if we optionally provide either an encoded metadata path, or a websocket endpoint from which the existing metadata can be fetched, we can compare the values, and if anything has changed, we emit a warning.

sub-xt can be useful to do all of these.

[ggwpez]

Having volatile constants is a weird design to begin with. I think a constant should be constant by definition.
Maybe:

#[pallet::constant] // non-volatile
#[pallet::variable] // volatile

[kianenigma]

totally agree, and taking it a step further, I think pallet::constant was bad to begin with because the name doesn't have much to do with the semantic, which is "put it in metadata".

#[pallet::metadat(constant)]
#[pallet::metadat(variable)]

[kianenigma]

related: #1139

[juangirini]

const fn could help us here

[bkchr]

const fn could help us here

No it doesn't help here. You could still change the value between different releases. This is nothing that const fn protects against.

[kianenigma]

Yeah correct. The right tool that would help us here is a metadata comparison tool.

[ggwpez]

This is mixing different meanings of the word "const".
Currently we do not support it. We could restrict it to only change on runtime upgrades. But hence since anything can change in a runtime upgrade, i think that is fine.

The problem with Get is that it can be implemented as a storage query, so it can arbitrarily change at any time. So I think using the Rust compile time notion of const does already help a lot for reasoning about things within a runtime.

Yeah correct. The right tool that would help us here is a metadata comparison tool.

This cannot guarantee anything within the runtime. It would only be helpful for the release process, to compare things (similar to subwasm diff). It does already detect constant changes in the metadata.

[kianenigma]

I will close this in favor of #1139. The metadata comparison (nested in construct_runtime) I proposed here, if one day implemented, would be interested in conjuncture with #218