solidity/docs/contracts/constant-state-variables.rst

74 lines
3.0 KiB
ReStructuredText
Raw Normal View History

2019-01-07 13:14:26 +00:00
.. index:: ! constant
2020-03-19 16:57:55 +00:00
**************************************
Constant and Immutable State Variables
**************************************
2019-01-07 13:14:26 +00:00
2020-03-19 16:57:55 +00:00
State variables can be declared as ``constant`` or ``immutable``.
In both cases, the variables cannot be modified after the contract has been constructed.
For ``constant`` variables, the value has to be fixed at compile-time, while
for ``immutable``, it can still be assigned at construction time.
The compiler does not reserve a storage slot for these variables, and every occurrence is
replaced by the respective value.
Not all types for constants and immutables are implemented at this time. The only supported types are
`strings <strings>`_ (only for constants) and `value types <value-types>`_.
::
// SPDX-License-Identifier: GPL-3.0
2020-06-23 16:11:34 +00:00
pragma solidity >0.6.99 <0.8.0;
2020-03-19 16:57:55 +00:00
contract C {
uint constant X = 32**22 + 8;
string constant TEXT = "abc";
bytes32 constant MY_HASH = keccak256("abc");
uint immutable decimals;
uint immutable maxBalance;
address immutable owner = msg.sender;
2020-06-23 16:11:34 +00:00
constructor(uint _decimals, address _reference) {
2020-03-19 16:57:55 +00:00
decimals = _decimals;
// Assignments to immutables can even access the environment.
maxBalance = _reference.balance;
}
function isBalanceTooHigh(address _other) public view returns (bool) {
return _other.balance > maxBalance;
}
}
Constant
========
For ``constant`` variables, the value has to be a constant at compile time and it has to be
assigned where the variable is declared. Any expression
2020-05-05 08:56:31 +00:00
that accesses storage, blockchain data (e.g. ``block.timestamp``, ``address(this).balance`` or
2019-01-07 13:14:26 +00:00
``block.number``) or
execution data (``msg.value`` or ``gasleft()``) or makes calls to external contracts is disallowed. Expressions
that might have a side-effect on memory allocation are allowed, but those that
might have a side-effect on other memory objects are not. The built-in functions
``keccak256``, ``sha256``, ``ripemd160``, ``ecrecover``, ``addmod`` and ``mulmod``
are allowed (even though, with the exception of ``keccak256``, they do call external contracts).
The reason behind allowing side-effects on the memory allocator is that it
should be possible to construct complex objects like e.g. lookup-tables.
This feature is not yet fully usable.
2020-03-19 16:57:55 +00:00
Immutable
=========
2019-01-07 13:14:26 +00:00
2020-03-19 16:57:55 +00:00
Variables declared as ``immutable`` are a bit less restricted than those
declared as ``constant``: Immutable variables can be assigned an arbitrary
value in the constructor of the contract or at the point of their declaration.
They cannot be read during construction time and can only be assigned once.
2019-01-07 13:14:26 +00:00
2020-03-19 16:57:55 +00:00
The contract creation code generated by the compiler will modify the
contract's runtime code before it is returned by replacing all references
to immutables by the values assigned to the them. This is important if
you are comparing the
runtime code generated by the compiler with the one actually stored in the
blockchain.