2019-01-07 13:14:26 +00:00
|
|
|
.. index:: ! constant
|
|
|
|
|
2020-09-30 19:31:28 +00:00
|
|
|
.. _constants:
|
|
|
|
|
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.
|
|
|
|
|
2020-09-30 19:31:28 +00:00
|
|
|
It is also possible to define ``constant`` variables at the file level.
|
|
|
|
|
2020-03-19 16:57:55 +00:00
|
|
|
The compiler does not reserve a storage slot for these variables, and every occurrence is
|
|
|
|
replaced by the respective value.
|
|
|
|
|
2020-07-27 08:40:33 +00:00
|
|
|
Compared to regular state variables, the gas costs of constant and immutable variables
|
|
|
|
are much lower. For a constant variable, the expression assigned to it is copied to
|
|
|
|
all the places where it is accessed and also re-evaluated each time. This allows for local
|
|
|
|
optimizations. Immutable variables are evaluated once at construction time and their value
|
|
|
|
is copied to all the places in the code where they are accessed. For these values,
|
|
|
|
32 bytes are reserved, even if they would fit in fewer bytes. Due to this, constant values
|
|
|
|
can sometimes be cheaper than immutable values.
|
|
|
|
|
2020-03-19 16:57:55 +00:00
|
|
|
Not all types for constants and immutables are implemented at this time. The only supported types are
|
2020-08-06 10:56:17 +00:00
|
|
|
:ref:`strings <strings>` (only for constants) and :ref:`value types <value-types>`.
|
2020-03-19 16:57:55 +00:00
|
|
|
|
2021-06-25 10:25:29 +00:00
|
|
|
.. code-block:: solidity
|
2020-03-19 16:57:55 +00:00
|
|
|
|
2020-05-13 15:45:58 +00:00
|
|
|
// SPDX-License-Identifier: GPL-3.0
|
2023-05-30 14:07:00 +00:00
|
|
|
pragma solidity ^0.8.21;
|
2020-09-30 19:31:28 +00:00
|
|
|
|
|
|
|
uint constant X = 32**22 + 8;
|
2020-03-19 16:57:55 +00:00
|
|
|
|
|
|
|
contract C {
|
|
|
|
string constant TEXT = "abc";
|
|
|
|
bytes32 constant MY_HASH = keccak256("abc");
|
2023-05-30 14:07:00 +00:00
|
|
|
uint immutable decimals = 18;
|
2020-03-19 16:57:55 +00:00
|
|
|
uint immutable maxBalance;
|
|
|
|
address immutable owner = msg.sender;
|
|
|
|
|
2022-02-16 02:59:49 +00:00
|
|
|
constructor(uint decimals_, address ref) {
|
2023-05-30 14:07:00 +00:00
|
|
|
if (decimals_ != 0)
|
|
|
|
// Immutables are only immutable when deployed.
|
|
|
|
// At construction time they can be assigned to any number of times.
|
|
|
|
decimals = decimals_;
|
|
|
|
|
2020-03-19 16:57:55 +00:00
|
|
|
// Assignments to immutables can even access the environment.
|
2022-02-16 02:59:49 +00:00
|
|
|
maxBalance = ref.balance;
|
2020-03-19 16:57:55 +00:00
|
|
|
}
|
|
|
|
|
2022-02-16 02:59:49 +00:00
|
|
|
function isBalanceTooHigh(address other) public view returns (bool) {
|
|
|
|
return other.balance > maxBalance;
|
2020-03-19 16:57:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
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
|
2023-05-30 14:07:00 +00:00
|
|
|
declared as ``constant``: Immutable variables can be assigned a
|
|
|
|
value at construction time.
|
|
|
|
The value can be changed at any time before deployment and then it becomes permanent.
|
|
|
|
|
|
|
|
One additional restriction is that immutables can only be assigned to inside expressions for which
|
|
|
|
there is no possibility of being executed after creation.
|
|
|
|
This excludes all modifier definitions and functions other than constructors.
|
|
|
|
|
|
|
|
There are no restrictions on reading immutable variables.
|
|
|
|
The read is even allowed to happen before the variable is written to for the first time because variables in
|
|
|
|
Solidity always have a well-defined initial value.
|
|
|
|
For this reason it is also allowed to never explicitly assign a value to an immutable.
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
When accessing immutables at construction time, please keep the :ref:`initialization order
|
|
|
|
<state-variable-initialization-order>` in mind.
|
|
|
|
Even if you provide an explicit initializer, some expressions may end up being evaluated before
|
|
|
|
that initializer, especially when they are at a different level in inheritance hierarchy.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
Before Solidity 0.8.21 initialization of immutable variables was more restrictive.
|
|
|
|
Such variables had to be initialized exactly once at construction time and could not be read
|
|
|
|
before then.
|
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
|
2022-06-19 06:26:03 +00:00
|
|
|
to immutables with the values assigned to them. This is important if
|
2020-03-19 16:57:55 +00:00
|
|
|
you are comparing the
|
|
|
|
runtime code generated by the compiler with the one actually stored in the
|
2023-05-15 15:21:03 +00:00
|
|
|
blockchain. The compiler outputs where these immutables are located in the deployed bytecode
|
|
|
|
in the ``immutableReferences`` field of the :ref:`compiler JSON standard output <compiler-api>`.
|