Solidity: mutable variables (immutable as default)

[ethers]

Function parameters can be marked immutable.

Such variables are called immutable. The immutable property extends to expressions in the following way:

• members of immutable expressions are immutable
• index access to immutable expressions yields immutable expressions
• (perhaps some other cases we forgot about)

Immutable expressions cannot be assigned to (or be used in ++ or -- expressions) and they cannot be passed to internal functions as arguments that are not marked as immutable.

For value types, the "immutable" property can be removed if they are rvalues (need to specify this some more), and also the transition from storage to memory and memory to storage can lose the immutable property.

Todo:

• [ ] similar to isPure, collect data in the TypeChecker about whether an expression is immutable
• [x] add the immutable keyword
• [ ] check that assignments and ++ and -- do not have immutable left-hand-sides
• [ ] check that there is no assignment from an immutable expression to a mutable expression
• [ ] check that arguments to function calls do not violate these rules

---

"The constant keyword for functions is currently not enforced by the compiler."

It sounds like Solidity can enforce this and refuse to compile.

[chriseth]

There are several stories like this still on pivotal tracker, will try to cross-link them.

[axic]

cc #992

[chriseth]

This would allow constant contract-level variables of struct and array type. If we enforce the constant keyword on those, arrays and struct members cannot be modified, not even if such constants are passed on to other functions.

Some end to end tests are disabled (referencing this issue 715) until we have constant contract-level variables of struct and array type.

[axic]

Some historical explanation on immutable is here: https://github.com/ethereum/solidity/pull/1049#discussion_r89112618

[roadriverrail]

To be clear, constant will continue to be used for state variables and functions, retaining its original semantics, yes?

[axic]

Until the next breaking release.

[roadriverrail]

Ah. So the use of constant is being completely replaced, then. I wasn't sure if this was to distinguish constant from immutable or to wholly replace it.

[axic]

It seems that constant will remain solely for compile time constants, which cannot refer non-constant statements.

[maurelian]

I initially intended to file this as a separate issue, but thought it made more sense to request it as an extension to this issue. I'm essentially advocating to include #3356 with this feature. I can open a new issue if it's preferred.

Motivation:

It's very common in Solidity contracts to include storage variables which are never intended to be modified. An example of this is decimals in EIP20. (examples: consensys, Zeppelin)

The decimals value should never change, but no one declares it as constant because they want to be able to set the value in the constructor.

This is both less safe, and more expensive because the values need to be written to and read from storage.

Proposal:

• immutable values should be appended to the runtime bytecode.
• The location of the values should be stored in bytecode at compile time
• Where constant values are currently placed on the stack using PUSH_, immutable values can be accessed using CODECOPY.

This approach has additional safety beyond compiler errors, as it's not possible to modify bytecode in the ethereum protocol.

That would look something like this:

contract Example {

    uint public constant I_AM_CONSTANT; 
    uint public immutable I_AM_IMMUTABLE;

    function Example(uint _b) public {
        I_AM_CONSTANT = _b; // TypeError: Cannot assign to a constant variable.
        I_AM_IMMUTABLE = _b; 
    }

}

[chriseth]

@maurelian this is a useful feature to have, but I think it is orthogonal to the current issue: It adds a feature instead of restricting the language.

[maurelian]

Thanks @chriseth, I'll open a new issue.

[axic]

Removing the label accepted here because I think this merits a thorough review in 0.5.1

[chriseth]

The default should be "immutable" and "mutable" the annotation.