Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access to constants through contract names #1290

Closed
ethernomad opened this issue Oct 26, 2016 · 14 comments
Closed

Access to constants through contract names #1290

ethernomad opened this issue Oct 26, 2016 · 14 comments
Labels
annoys users 😢 closed due inactivity The issue/PR was automatically closed due to inactivity. help wanted language design :rage4: Any changes to the language, e.g. new features low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. stale The issue/PR was marked as stale because it has been open for too long.

Comments

@ethernomad
Copy link
Contributor

It is currently possible to do this:

pragma solidity ^0.4.3;

contract Constants {

    uint constant FLAG = 0x1;
}

contract Test is Constants {

    function x() returns (uint) {
        return Constants.FLAG;
    }
}

But surely it should be possible to do this:

pragma solidity ^0.4.3;

contract Constants {

    uint constant FLAG = 0x1;
}

contract Test {

    function x() returns (uint) {
        return Constants.FLAG;
    }
}
@chriseth
Copy link
Contributor

We still have to figure out how we want constants to behave exactly. Currently, I think you might be able to access private information via constants, which is perhaps not such a good idea.

@chriseth
Copy link
Contributor

Now that we have the pure check, it should be fine to do this at least for actually pure constants.

@j-h-scheufen
Copy link

As a side note to this ticket: To simulate the desired constant behavior until it's fully supported in the language I'm using a workaround via libraries:

library Constants {
   function FLAG() pure returns (uint) {
      return 0x1;
   }
}

contract Test {
    function x() returns (uint) {
        return Constants.FLAG();
    }
}

To be frank, I actually don't know the cost of simulating constants via library functions, because you have an additional function on the callstack and memory every time you access it, but it does the trick and gives me what I need for more efficient coding. Once constants are supported fully, it is not too hard to turn the library into a contract and search/replace its usage to remove the () parentheses.

I'm not worried about gas cost as the solutions that use this approach run on a permissioned EVM with no gas limit, but it would be great to get your opinion on the above, @chriseth.

@axic
Copy link
Member

axic commented Mar 21, 2019

I am leaning towards that constants should be supported in interfaces instead.

@cygnusv
Copy link

cygnusv commented Apr 6, 2020

It seems this is solved with Solidity 0.6

@chriseth chriseth closed this as completed Apr 8, 2020
@j-h-scheufen
Copy link

I looked at the Solidity 0.6 release notes and did not see how this is solved with that release. Can anyone point to an example or other relevant docs?

@chriseth
Copy link
Contributor

Ah sorry, I thought I tried the example, but I must have made a mistake.

@sambacha
Copy link

can confirm, 100% still an issue

@chriseth
Copy link
Contributor

Design call: moving it into the icebox because there seems to be not too much interest. We may allow constants at file level in the future instead.

@cameel
Copy link
Member

cameel commented Sep 3, 2020

Just for reference - issue about constants at file level: #9671.

@pedrommaiaa
Copy link

This is still an issue on 0.8.15:

Contract Test1 {
    uint256 public constant WAD = 1e18;
}

Contract Test2 {
    function getWad() external pure returns (uint256) {
        return Test1.WAD();
    }
}

returns Member "WAD" not found or not visible after argument-dependent lookup in type(contract Test1).

@itaborda
Copy link

I also believe that something like this would be perfectly possible

type(ContractWithConstant).CONSTANT_NAME

very similar to

type(uint).max

@cameel cameel added low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. language design :rage4: Any changes to the language, e.g. new features labels Sep 28, 2022
@github-actions
Copy link

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

@github-actions github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label Feb 12, 2023
@github-actions
Copy link

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.

@github-actions github-actions bot added the closed due inactivity The issue/PR was automatically closed due to inactivity. label Feb 20, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
annoys users 😢 closed due inactivity The issue/PR was automatically closed due to inactivity. help wanted language design :rage4: Any changes to the language, e.g. new features low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. stale The issue/PR was marked as stale because it has been open for too long.
Projects
None yet
Development

No branches or pull requests

10 participants