Is it ok to define constants in upgradable contracts with ZeppelinOS?

I know we should avoid initial values in field declarations with ZeppelinOS, but what about for constants?

(A) Should we change them to non-constants even though they will in effect be used as constant to avoid the Uninitialized constant variable lint warning?

OR

(B) Is it okay for a constant still to be defined in the contract with ZeppelinOS?

Thanks!

1 Like

Hi @pcowgill welcome to the forum. It would be great if you could share with the community what you are working on.

I assume that it is ok to define constants in an upgradeable ZeppelinOS contract based on the Solidity documentation for how constants work:

https://solidity.readthedocs.io/en/latest/contracts.html#constant-state-variables
The compiler does not reserve a storage slot for these variables, and every occurrence is replaced by the respective constant expression (which might be computed to a single value by the optimizer).

Not all types for constants are implemented at this time. The only supported types are value types and strings.

I added a constant to the sample contract used in the ZeppelinOS tutorial: https://docs.zeppelinos.org/docs/deploying.html

ZeppelinOS didn't show any warnings or errors and I was able to access the value of the constant from truffle console as I would expect.

pragma solidity ^0.5.0;

import "zos-lib/contracts/Initializable.sol";

contract MyContract is Initializable {

    uint256 public x;
    string public s;
    uint256 constant public y = 23;

    function initialize(uint256 _x, string memory _s) initializer public {
        x = _x;
        s = _s;
    }
}
2 Likes

Thanks for the quick response. Yep, I can confirm that this worked for me as well.

I just made a PR to add this to the docs: https://github.com/zeppelinos/zos/pull/1036

2 Likes

Thanks for making a PR. That is awesome.

1 Like