Hi Solidity Core development team, do you plan to support high-level syntax like this? Can I open a pr for this?
Complexity type for transient and constant variables:
Example :
mapping(address => uint256) transient var1;
bytes32[5] constant var2;
bytes immutable var3;
Advantages: Allows the implementation of complex structures without using assembly, such as building lookup tables directly within the existing contract without going through the blueprint contract and increase the number of use cases for transient storage.
long-byte:
Definition: A static byte array with a size greater than 32 bytes (the maximum size of an operand on the stack)
Example:
bytes33 var4;
bytes64 calldata var5;
Note that the declaration rules for long-byte variables are similar to those for dynamic bytes type variables.
Advantages: Allows the creation of deterministic byte sequences longer than 32 bytes without padding, unlike dynamic byte arrays.
We hope the Solidity Core developers will consider this.
These would indeed be nice to have, but they’re not very straightforward to implement.
The EVM is a 32-byte stack machine, so types like bytes64 would require multi-word operations for everything, adding compiler complexity and non-obvious gas costs. I am not sure it’s worth the added complexity.
For transient complex types, the compiler would essentially need to rebuild all the machinery it uses for regular storage, but for a new storage domain, which is a substantial effort with real risk if the semantics are wrong. And constant mappings are architecturally incompatible with how constant works today.
No one is preventing you from opening a PR, but it’s likely to be a significant undertaking on your end and could be wasted effort if these features don’t align with the language’s short- to mid-term plans.
I want to clarify the semantics of each syntax to avoid misunderstandings during implementation.
For long-byte types as mentioned, we can implement them like regular reference types such as bytes except that they don’t have padding, no one is forcing them to be placed on a stack if they can’t. The addition of the long-byte type allows for the packaging of static data larger than 32 bytes in a gas-efficient manner thanks to the absence of padding, which is particularly important as the network continuously increases calldata fees (EIP-7623 and later EIP-7976), a growth that will eventually exceed transaction costs. Furthermore, since long-byte is also a byte array, it also allows indexed access continuously instead of page-based like bytes32[len], this becomes useful when writing optimization algorithms.
For transients, we can inherit the design currently used for regular storage. We might be concerned about the layout of transients being compatible with regular storage, but we already have the ERC-7201 namespace. The use of transients is highly encouraged by the Ethereum protocol, if we had more complex structures for it, we would see more use cases, such as ERC-20 temporary approval.
For constant types, I don’t require additional mapping as that’s a design limitation. However, other feasible structures like array or struct would be extremely useful for building inline lookup tables by leveraging redundant bytecode space. The maximum bytecode size will increase in the next update, leveraging this space instead of querying through blueprint contracts will significantly reduce access costs.
It’s not necessary to deploy all of them in a single upgrade; they can be broken down into smaller phases. However, these improvements will become useful as AA evolves and new designs may require more powerful compilers to allow them to reach their full potential.
I want the compiler to do its best – add what it can add.
The thing though is that they’re mostly on a backburner now since we’re working on much higher priority items (SSA CFG backend, ethdebug, Core Solidity) and don’t have the bandwidth to open new big topics until we’re done with at least one of these. This includes reviewing related PRs as that’s always a significant effort on our side. All of these also still have open design questions that have to be hashed out first. I would always be helpful to talk about their design, but it’s not the right time to start implementing them.
For long-byte types as mentioned, we can implement them like regular reference types such as bytes
The idea is valid, but we are not planning on had-coding more features like this in the compiler. They should be implemented by third-party libraries. The language is not powerful enough to allow that yet, but that’s why we’re working on Core Solidity.