Introduce deployment-time constants

[3sGgpQ8H]

Abstract

We suggest introducing new kind of state variables: deployment-time constants. Such variables may be assigned only once in the constructor of a smart contract. Constructor should inject values, assigned to such variables, directly into byte code at places where they are read.

Motivation

Currently Solidity has compile-time constants. Values of such constants have to be known at compile time, so compiler directly substitutes these values into byte code where they are used. Compile-time constants do not occupy storage space, and are cheap to deploy and read.

Though, many real-life contracts contain state variables that are assigned only once in the constructor. These variables couldn't be declared as constant because their values are not known at compile time. Such variables occupy storage space and are relatively expensive to deploy and read. Also, it is hard to verify that value of such variable never changes, especially for contracts that have inline assembly sections.

Deployment-time constants, whose values are injected at deployment time directly into byte code, would be cheaper to deploy and read. They would be guaranteed to be immutable.
Also, this feature will allow contracts, that are supposed to be called only via DELEGATECALL (e.g. new versions of upgradeable contracts), to save their original address into deployment-time constant and later use it to ensure that the contract was actually called via DELEGATECALL.

Specification

Introduce new access level specifier, e.g. final, applicable for state variables of atomic types. State variables marked with this specifier should be assignable only once in the constructor of the smart contract. Constructor should inject assigned value directly into byte code. In case variable it read in only one place, the value should be injected into this place. In case there are multiple places where variable is read, compiler should generate internal getter function for the variable, and use it for reading variable, so this getter functions will be the only place within byte code where variable value is accessed directly.

Backwards Compatibility

The change will introduce new keyword, e.g. final, which will break compatibility with existing smart contracts that use this keyword as an identifier.

[leonardoalt]

Hi @3sGgpQ8H , thanks for the request.
This sounds like a duplicate of #3835, can you confirm?

[3sGgpQ8H]

#3835 proposes about the same functionality, but suggests different slightly different approach. I think yes, this could be considered duplicate.

[asymmetric]

Can this be closed then?