Better syntax for declaring nested mappings.

[Amxx]

At some point today I found myself declaring the following mapping:

mapping(bytes32 => mapping(bytes32 => mapping(bytes32 => mapping(uint256 => MyEntry)))) internal m_lookuptable;

I get this is a bit of an extreme case, but I might not be the only one nesting mappings. So I wondered, why not replace it with:

mapping(bytes32 => bytes32 => bytes32 => uint256 => MyEntry) internal m_lookuptable;

It should be pretty easy for the parser to adapt to this syntax, no backend modification should be necessary, and the result would be much more readable.
Also, it doesn't break anything, so backward compatibility would be unaffected.

[chriseth]

Thanks for your suggestion, @amaxx! I'm wondering whether you really need a data structure that support "partial evaluation" or if what you really need is tuples as keys for mappings.

So it would rather be

mapping(bytes32, bytes32, bytes32, uint256 => MyEntry) internal m_lookuptable;

and you would use m_lookuptable["1", "2", "3", 1] instead of m_lookuptable["1"]["2"]["3"][1]

It would also have the benefit that you only need to compute one hash instead of 4.

[axic]

Perhaps using the tuple syntax we have is more clear:

mapping((bytes32, bytes32, bytes32, uint256) => MyEntry) internal m_lookuptable;

[axic]

Btw @Amxx, it occurred to me that you can (almost) already do this albeit at a memory cost: can use a single bytes32 key and hash your keys (keccak256(abi.encode(a, b, c,...))). With bytes.concat (#10903) this should be clarified to keccak256(bytes.concat(a, b, c, ...).

So basically the tuple syntax is a memory-efficient and more easy to ready alternative to the above.

We should keep in mind that potentially the codegen should be able to avoid the memory overhead, if it is clever enough.

[cameel]

We discussed it briefly today and it does not look like it's compatible with the direction we want the language to go. It's a nice bit of syntactic sugar but conflicts with the fact that we'd like mappings to eventually stop being special and become a user-defined generic type provided by the standard library, implementable using other language primitives.

We're also planning to introduce proper, nameable tuple types at some point. This should be a good enough alternative to this feature and would work the way @axic has shown above: #8499 (comment).

[Amxx]

We're also planning to introduce proper, nameable tuple types at some point. This should be a good enough alternative to this feature and would work the way @axic has shown above: #8499 (comment).

I would consider this a solution to this issue! Any timeframe on this ?

[cameel]

Not sure actually. It's not directly on the roadmap but I think it might be a prerequisite of some other roadmap task. @ekpyron?

[ekpyron]

We haven't really discussed the timeframe of those yet - it's one of the issues that makes our type system more regular and would prepare it for an easier transition to a type system including full generics, like tying data locations to types instead of variables. We could target them in the vicinity of #13365 (which is staged for Q2), but yeah, not entirely clear yet.