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

Allow constants in interfaces #8775

Closed
axic opened this issue Apr 25, 2020 · 4 comments
Closed

Allow constants in interfaces #8775

axic opened this issue Apr 25, 2020 · 4 comments
Labels
closed due inactivity The issue/PR was automatically closed due to inactivity. 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. medium impact Default level of impact stale The issue/PR was marked as stale because it has been open for too long.

Comments

@axic
Copy link
Member

axic commented Apr 25, 2020

(Moved this from #3411 which, now confusingly, refers to a different feature.)

Since we allow accessing constants through contract names (#1290) and enums in interfaces (#4087), it may make sense to reconsider this feature, at least for some healthy discussion.

I am still not sure if it is a good idea or not (it definitely can be useful from a users' perspective, but could be dangerous?)

The case I ran into is the following (ralexstokes/deposit-verifier#2):

interface DepositContract {
    uint constant PUBLIC_KEY_LENGTH = 48;
    uint constant SIGNATURE_LENGTH = 96;

    function deposit(
        bytes calldata publicKey,
        bytes32 withdrawalCredentials,
        bytes calldata signature,
        bytes32 depositDataRoot
    ) external payable;
}

In this example the interface uses basic types (bytes), but they have a limit enforced (the two constant above) so it would be useful from the caller to have require statements:

contract DepositProxy {
    function verifyAndDeposit(...) public {
        require(publicKey.length == DepositContract.PUBLIC_KEY_LENGTH, "incorrectly sized public key");
        require(signature.length == DepositContract.SIGNATURE_LENGTH, "incorrectly sized signature");

        // ...

        DepositContract(0x...).deposit(...);
    }
}
@axic axic added the language design :rage4: Any changes to the language, e.g. new features label Apr 25, 2020
@axic
Copy link
Member Author

axic commented Apr 27, 2020

Note, #8772 fixes the use case I would need this for. Not sure if there are other common use cases.

@axic
Copy link
Member Author

axic commented Jun 16, 2022

This would be still a nice feature.

@cameel cameel added the feature label Jun 16, 2022
@cameel cameel added good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. low effort There is not much implementation work to be done. The task is very easy or tiny. medium impact Default level of impact labels Sep 26, 2022
@ekpyron ekpyron removed the good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. label Jan 5, 2023
@github-actions
Copy link

github-actions bot commented Apr 5, 2023

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 Apr 5, 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 Apr 13, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed due inactivity The issue/PR was automatically closed due to inactivity. 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. medium impact Default level of impact 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

4 participants