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
Syntax improvement for ResultQuery
usage
#259
Comments
I don't get this? What you mean by this? TBH, I don't get the entire issue. You want to improve the syntax, but from what to what? What kind of syntax do you would like to see? I mean yes, this is currently not standard Rust and I don't see it being transformed to standard rust in the near future if we don't want to have very complicated syntax. Why can we not accept error variants that have fields? As long as these fields are const initialized? |
There's only a finite amount of customization that we can make on top of the standard Rust syntax, before it gets too strange and hurts discoverability and hence usage. We can't always rely upon documentation to expose certain programming features that pallets support, and so the more we deviate from standard Rust, the more unexpected syntactical constructs that we have to maintain and explain. If we want Substrate to be the prime tool for people to use to build blockchains, then devex is a goal that we should strive for. The existence of customized syntax like this one makes it impossible for us to continue to claim that "if you know Rust, you know Substrate", as we're clearly creating our own dialect of Rust. Functionality-wise, we can indeed parse any syntax and make things work, but that is not what this issue is focused on. We need to reduce our strangeness factor. |
Never heard this claim since I work at Substrate ;) Nevertheless, back to the topic. Could you give an example from current syntax to what syntax you would like to change? |
At the very least, I think the Then the question becomes "how do we specify the error variant to use for the |
"idiomatic" is just such a random word in Rust that everyone uses, but that has actually no real meaning.
|
paritytech/substrate#11257 introduces
ResultQuery
, which contain syntax that is in fact non-standard Rust when trying to use it as theQueryKind
type parameter for a storage map. Example:The reason here is because
Error<T>::NonExistentStorageValue
is not a type, but rather a value, as enum variants are currently not properly recognized as their own proper types in Rust.In addition, such a syntax does not cater to enum variants that accept fields, so implementors are forced to also use the
OnEmpty
parameter to specify what the defaultResult
value should be when the corresponding value doesn't exist under the storage key specified.We'd like to try and stick with standard Rust syntax as much as possible, and as a stretch goal, also allow for the flexibility of specifying the default query value without the usage of
OnEmpty
.The text was updated successfully, but these errors were encountered: