Interfaces can't inherit

[fulldecent]

The following fails to compile. I make a case here that it should.

pragma solidity ^0.5;

interface I1 {
    function a() external;
}

// ✅ Test 1 -- should pass 
interface I2 is I1 {
    function b() external;
}

// ✅ Test 2 -- should pass 
interface I3 is I1 {
    function a() external override(A);
}

Why?

Best practice now is for ERCs to publish a Solidity interface. This defines a standard for compliant contracts to implement.

Examples: ERC-721, ERC-777, ERC-1155, ERC-875 (DRAFT). (This is every Final and Last Call ERC since 721.)

Very often (most of the above examples) the standards author will specify that implementing a standard requires implementing another standard as a prerequisite. For example to implement ERC-721 it is specified that you must implement ERC-165. To implement the ERC-721 Metadata Extension it is specified that you must first implement ERC-721.

Currently, authors are expressing this in code like:

/// @title ERC-721 Non-Fungible Token Standard
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x80ac58cd.
interface ERC721 /* is ERC165 */ {
    // ...
}

This can be adopted formatting in the language.

Related

• Support ERC-165 identifiers #7856

[axic]

Why would it need to extend another interface? A contract can inherit multiple interfaces.

[fulldecent]

Here's why:

pragma solidity ^0.4.19;

interface A {
    uint32[] public contracts;
}

interface B is A {
    function lastContract() public returns (uint32 _contract);
}

Interface B depends on A. This fact should be encodable in B, and it can be done with inheritance.

[fulldecent]

When you are writing ERC20Equity you will want to be sure it complies with the ERC20 interface. And that should be enforced and checked by the compiler.

[ondratra]

Why is this still not solved? This is must have for interfaces. Can I help with implementation or what's the status on this?

[fulldecent]

Because I’m not a paid employee.

Please see the discussion on reinventing inheritance in the other issue. And we are reviewing the finer details of this change. On cell phone, sorry no link.

[ondratra]

Not sure what is current issue i should check, can you send me link?

I think this "interface composition" could be implemented right away without changes seen here. I am willing to help with it.

[chriseth]

@ondratra thank you for your offer, but the implementation is not the issue. The problem is that we want to properly fix inheritance and function overloading, and this requires some discussion. Please take a look here: #3729

[branaway]

Desperately need interface inheritance for clean OOD!

[k06a]

Interfaces are unusable until inheritance implemented.

[fulldecent]

The current workaround is to use:

/* interface */ contract ERC721 {
  ...
}

I hear you loud and clear. Progress to fix this issue is happening at #3729

[nfurfaro]

It seems like an interface should stand on it's own, without needing to inherit. A collection of small, specific interfaces can be composed by a contract which inherits them. I don't think an interface should depend on anything else.

[fulldecent]

@nfurfaro I disagree.

The intent of the meaning "Interface A inherits interface B" can also be stated as "interface A requires interface B". This is a common concept and the compiler should understand it.

Here is just one example:

https://github.com/0xcert/ethereum-erc721/blob/master/contracts/tokens/ERC721Metadata.sol is an interface with three functions. It is specified in documentation that using this interface only makes sense if you also implement the interface https://github.com/0xcert/ethereum-erc721/blob/master/contracts/tokens/ERC721.sol

The former literally means nothing without the latter.

[k06a]

@fulldecent you're right, but I prefer "interface A extends interface B". I OOP meaning, interface A is more specific than interface B.

[nfurfaro]

@fulldecent I see your point. Can this be achieved using Abstract contracts? Use a single Abstract contract as a base contract for the implementation, and the Abstract contract can inherit as many interfaces as needed. I realize this doesn't quite codify the relationship between the 2 interfaces in your example in the same way that interface inheritance would.

[nfurfaro]

Can we not accomplish this with Abstract contracts?

On Mon, Oct 22, 2018, 1:47 AM Anton Bukov, ***@***.***> wrote: @fulldecent <https://github.com/fulldecent> you're right, but I prefer "interface A extends interface B". I OOP meaning, interface A is more specific than interface B. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3419 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQQ1lDt_xBYMBQfn-JXVdplv4KNuZAQTks5unXgWgaJpZM4RmABW> .

-- Nick Furfaro

[fulldecent]

Yes, an abstract contract or a contract is able to achieve the same thing. But semantics are lost.

Semantically, inter-contract communication is described by interfaces (which represent Ethereum ABI). If people that are standardizing inter-contract communication (🤚) are using interfaces that implement or extend other interfaces then this behavior is more semantic to be in interfaces.

[nfurfaro]

Got it. Thanks for the clear rationale behind it.

On Mon, Oct 22, 2018, 5:56 PM William Entriken, ***@***.***> wrote: Yes, an abstract contract or a contract is able to achieve the same thing. But semantics are lost. Semantically, inter-contract communication is described by interfaces (which represent Ethereum ABI). If people that are standardizing inter-contract communication (🤚) are using interfaces that implement or extend other interfaces then this behavior is more semantic to be in interfaces. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3419 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQQ1lN-xd3A8yjl97wjGhdVdJ2ctNFnZks5unlsrgaJpZM4RmABW> .

-- Nick Furfaro

[fulldecent]

Issue updated and references added per weekly meeting today.

[axic]

Didn't we agree on the lat meeting that we should allow interfaces to inherit to signal dependency, but they cannot override any specifications?

[chriseth]

@axic sounds good!

[fulldecent]

@axic Yes. Sorry for the omission. I have corrected the test cases in the top comment.

[wjmelements]

I'm glad to see this will finally make it into solidity.

[k06a]

Hope to see this “interface extending” feature soon, to avoid using “abstract contracts” for this purpose

[nfurfaro]

Agreed. Happy to see this moving forward!

…

On Wed., Dec. 18, 2019, 1:09 a.m. Anton Bukov, ***@***.***> wrote: Hope to see this “interface extending” feature soon, to avoid using “abstract contracts” for this purpose — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3419?email_source=notifications&email_token=AECDLFC5TNN2MHMW322RMK3QZHLFDA5CNFSM4EMYABLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHFJERA#issuecomment-566923844>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AECDLFHQMFO7ZPRPPIX5MODQZHLFDANCNFSM4EMYABLA> .

[randomnetcat]

Another ambiguous test case:

interface A {
    function test() external returns (uint256);
}

interface B {
    function test() external returns (uint256);
}

// Accepted or error?
interface Sub is A, B {}

[axic]

@random-internet-cat good catch. I don't think we should use the current inheritance rules in this case. It should be an error if there are conflicting definitions in the interfaces.

[leonardoalt]

@axic @random-internet-cat The current inheritance rules do issue an error for this case (with abstract contract instead of interface), and I think it should be an error there too:
Error: Derived contract must override function "test". Two or more base classes define function with same name and parameter types.

[chriseth]

@axic I disagree. We should provide a means to say "yes, these two functions in the interface actually mean the same thing". The following is legal:

pragma solidity ^0.6.0;
interface A {
    function test() external returns (uint256);
}

interface B {
    function test() external returns (uint256);
}

abstract contract Sub is A, B {
    function test() external virtual override(A,B) returns (uint256);
}

And thus this should also be legal (note no "virtual"):

pragma solidity ^0.6.0;
interface A {
    function test() external returns (uint256);
}

interface B {
    function test() external returns (uint256);
}

interface Sub is A, B {
    function test() external override(A,B) returns (uint256);
}

[ekpyron]

I fully agree with @chriseth on this one.
Overriding with unimplemented functions was added exactly for this purpose - it actually makes even more sense for interfaces than for abstract contracts.
I'd say we spent quite a lot of effort to design the contract inheritance rules to nicely deal with all cases like this, so I'm pretty sure we can and should use the very same rules for interfaces.

[randomnetcat]

So the contract labeled as "Test 2" in the original message should be permitted, since it would be permitted under the usual inheritance rules?

[ekpyron]

@random-internet-cat That's probably the one thing that needs discussion.
I myself would say: yes, "Test 2" is valid (of course only with an explicit override specifier). But I'm not sure everyone agrees on that.

I'd argue that we could indeed disallow all cases of "useless overriding with unimplemented functions" (i.e. it's only valid to override with unimplemented functions, if there are multiple ambiguous base functions), but I'm not sure about that and even if we want to, then I'd do that not only for interfaces, but also for (abstract) contracts (which would strictly speaking be breaking). So I would decouple this from the initial implementation of interface inheritance and consider it a separate issue.
So for now as far as I'm concerned the only difference between contract and interface inheritance should be that interface functions are all implicitly virtual.

[chriseth]

Second that:

"So for now as far as I'm concerned the only difference between contract and interface inheritance should be that interface functions are all implicitly virtual."

[chriseth]

accepted the above in the meeting.

[fulldecent]

Thank you. Test case at top is updated.