I was trying to decode call data and make assignment to struct members in one call. It’s okay to do it only for struct members, but not okay to mix new variables on the left hand side. See examples below. runTest works fine but runTest2 and runTest3 do not. Can see an error message like this “ParserError: Expected ‘,’, but got identifier for the lines address _asset”. Wondering why and if it’s possible to make it work. Thanks.
Thanks for the detailed answer. This is very clear. Just wondering why this is designed this way. Is it possible to allow both declaration and non-declaration assignments using tuples? Sometimes, it is memory efficient and can improve code readability. Thanks.
As to why it was done this way - I have no idea, since it was before my time. Maybe @chriseth or @daniel can chime in. As to whether it’s possible - at the moment, no, but technically I don’t see why it couldn’t be implemented. None the less, the next main thing is generics, and until those are fleshed out and implemented, we’re likely not going to be addressing this (or anything type related), as it would just over complicate things later on.
To add to @nikola-matic’s answer, we won’t be allowing this because the current syntax is a bit irregular and we’re trying to move away from such irregularities. If you look at it closer, it’s a really odd construct with arbitrary limitations:
It’s a mix between a destructuring expression and a declaration. You cannot do that with other types, e.g. arrays.
You can only do it for local variables. Not for state variables or constants at file-level.
It can be nested only one level deep. E.g. ((uint x, uint y), uint z) = ((1, 2), 3) is not allowed.
If we allowed using existing variables in it, the mix would become even weirder. We want to go in the opposite direction. We’re going to introduce proper, nameable tuple types in the not-so-distant future and the syntax will likely become (uint, uint) x = (1, 2) instead. And destructuring will become just another type of an expression, usable not just with tuples.