argotorg / argotorg/solidity

Ability to override function selectors to support external interfaces not expressible in valid syntax.

Open
#11,819 21 comments 0 reactions 0 assignees View on GitHub
language design :rage4: low effort medium impact must have eventually needs design
Dominant language
C++
Stars
25.7k
Forks
6.2k
Avg merge
2d 19h
Merged PRs (30d)
29

Description

Came up in https://github.com/ethereum/solidity/issues/11743, earlier in https://github.com/ethereum/solidity/issues/1687, resp. https://github.com/ethereum/solidity/issues/8081

We need a way to override function selectors in interfaces for two reasons:
- We might ourselves add new keywords to the language which might break backwards compatibility with contracts with an entry point with that name.
- Third-Party languages might allow selectors that collide with keywords or are otherwise incompatible with regular solidity function definitions.

We seem to have pretty much consensus on that we want this, but we require good syntax for it.

One option (I myself dislike) would be a modifier-style decorator at various positions with various names.
```
interface C
{
function errorCompat() selector(0x01020304) external returns (uint);
function errorCompat2() signature("error()") external returns (uint);
}
```
To me it seems like those are not prominent enough, though, among visiblity and mutability.

We had the idea to use ``= Base.f;`` for disambiguating during inheritance at some point, along those lines a possiblity would be:

```
interface C
{
function errorCompat() external returns (uint) = "error()";
function errorCompat2() external returns (uint) = 0x01020304;
}
```
Might be good to force encapsulation in a call-like construct, e.g. ``= externalSignature("error()")``, but choosing a name for that may be hairy.

Another option would be to borrow from the call option syntax, e.g.
```
interface C
{
function{ signature = "error()" } errorCompat() external returns (uint);
function{ selector = 0x01020304 } errorCompat() external returns (uint);
}
```
advantage: extensible if we ever need further similar annotations (e.g. if we ever want to break the ABI encoding, we could select a version here). No need for making ``selector`` (or anything) a keyword.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the linked issues 11743, 1687, and 8081, then compare the proposed selector and signature syntax options in this issue. Done means the project has an agreed, implementable way to express externally defined function selectors or signatures without valid Solidity syntax collisions.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, solidity
Domain
blockchain, compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.