Allow using pure functions in assignment to constant variables

[joeykrug]

E               /home/ubuntu/workspace/tests/solidity_test_helpers/Constants.sol:34:45: TypeError: Initial value for constant variable has to be compile-time constant.
E                   uint256 public constant GAS_TO_REPORT = Reporting.gasToReport();

I have a contract I'm trying to compile that imports another contract with a pure / constant function as below:

    uint256 private constant GAS_TO_REPORT = 600000;

    function gasToReport() internal pure returns (uint256) { return GAS_TO_REPORT; }

Any idea why it's saying Initial value for constant variable has to be compile-time constant. for this line: uint256 public constant GAS_TO_REPORT = Reporting.gasToReport(); ?

[axic]

Only a limited set of expressions are accepted as "pure" for compile-time constants and currently pure functions are not part of that.

Though it may be feasible lifting that restriction since we have a visibility checker in place now, though I would rather opt to restrict it even further (sha256/ripemd160 is part of it, yet it will compiled into a call and that is counterintuitive).

[axic]

I'd argue against allowing any pure function in constant variables before #3157 is sorted out.

[k06a]

Any progress on this?

[cameel]

The current status is that this depends on #3157, and that one first needs some design decisions from @ekpyron. It's one of our roadmap goals for this year, but we also have immutable reference types on the roadmap and I think @ekpyron will be working on them first.

The question is also how breaking it will be. Changing how pure works would definitely be breaking and would have to be scheduled for 0.9.0. But I think we're more likely to leave pure as is and introduce a new mutability level for functions that can be evaluated at compilation time and I think could be done in 0.8.x.

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[ekpyron]

I'm closing this as part of #13724, resp. #3157