# Making interfaces structural **URL:** \ **Category:** Language Design\ **Created:** [August 13, 2023, 3:56pm UTC](https://forum.soliditylang.org/t/making-interfaces-structural/1790 "2023-08-13T15:56:55Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![frangio](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/frangio/32/673_2.png) [@frangio](https://forum.soliditylang.org/u/frangio)\ **Post date:** [August 13, 2023, 3:56pm UTC](https://forum.soliditylang.org/t/making-interfaces-structural/1790/1 "2023-08-13T15:56:55Z")
There’s at least two issues with how interfaces currently work. 1. Overrides. I’ve argued before how `override(A, B)` is often unnecessary ([Thoughts on override(A, B) syntax](http://forum.soliditylang.org/t/thoughts-on-override-a-b-syntax/767)). Interfaces are one very clear instance of this. It should never be necessary to write `override(AnInterface, ...)` because there is nothing to disambiguate in terms of implementation. 2. Conflicting imports. Contracts often declare their arguments using interface types instead of addresses to be explicit about the functions that are expected from a contract. This creates unnecessary issues when the interface type present at the call site is structurally the same but nominally different from the one used at the function declaration site. Example: [https://twitter.com/PaulRBerg/status/1685352565678931969](https://twitter.com/PaulRBerg/status/1685352565678931969) These two issues could be solved by turning interfaces into a construct that is structurally typed. In this model, a contract that implements the functions needed for an interface would be automatically considered to implement that interface in the type system, and would be automatically cast to it when necessary. It should still be possible to explicitly state that a contract implements an interface, to have the compiler check that the contract definition satisfies the interface. This should not, however, affect linearization at all (for which there is a now-closed issue [#13136](https://github.com/ethereum/solidity/issues/13136)). No syntactic change seems strictly necessary, but there is a question about whether interfaces should still be listed in the `is ...` part of a contract definition. Currently interfaces are a kind of contract, and it’s debatable whether under this proposal they should continue to be seen as such. The alternative would be to have a form like `contract Foo implements IFoo is Parent1, Parent2 ...`. I would propose to keep them as part of the `is ...` statement to avoid introducing a new syntactic form. ---
**Author:** ![paulrberg](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/paulrberg/32/537_2.png) [@paulrberg](https://forum.soliditylang.org/u/paulrberg)\ **Post date:** [August 13, 2023, 6:37pm UTC](https://forum.soliditylang.org/t/making-interfaces-structural/1790/2 "2023-08-13T18:37:52Z")
Big time in favor of this proposal. It would make Solidity a better language to write libraries for. ---
**Author:** ![ekpyron](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/ekpyron/32/62_2.png) [@ekpyron](https://forum.soliditylang.org/u/ekpyron)\ **Post date:** [August 14, 2023, 1:37pm UTC](https://forum.soliditylang.org/t/making-interfaces-structural/1790/3 "2023-08-14T13:37:10Z")
I’d generally be in favour of disentangling external interfaces from contracts and especially from inheritance - however, I’m a bit sceptical about automatically instantiating contract types to interfaces by merit of them defining the required functions - I’d prefer that to generally remain explicit. You _can_ have structurally identical interfaces that are semantically different or even more easily have two independent interfaces combine to a third interface that semantically differs from the combination of the two - I’d rather make it easier (or possible without pains in the first place) to specifically declare two interfaces identical (which currently is a hassle). I’m wondering whether out-of-declaration statements indicating that contracts implement interfaces would be a good idea - I’m generally wondering whether in the long run, “contracts” may better be defined by explicitly synthesizing an external interface/dispatch that merely acts on separately defined storage areas, even though that would be a more aggressive change to the current language. ---
**Author:** ![frangio](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/frangio/32/673_2.png) [@frangio](https://forum.soliditylang.org/u/frangio)\ **Post date:** [August 14, 2023, 3:19pm UTC](https://forum.soliditylang.org/t/making-interfaces-structural/1790/4 "2023-08-14T15:19:49Z")
> [@ekpyron](#): > > You _can_ have structurally identical interfaces that are semantically different This might be true. One possible example that often shows up is the `transferFrom(address,address,uint256)` function that is defined both in ERC-20 and ERC-721 with completely different semantics (`uint256 amount` vs `uint256 tokenId`). However, the interfaces have other functions that clearly draw a distinction, e.g. `IERC721` would have `ownerOf(uint256)`. So I don’t think this should be a concern. In fact, if your contract only uses the `transferFrom` function it is the case that it will also work with ERC-721 tokens and the language would be faithfully representing that. ---
**Author:** ![simplemachine92](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/simplemachine92/32/1055_2.png) [@simplemachine92](https://forum.soliditylang.org/u/simplemachine92)\ **Post date:** [August 17, 2023, 7:19pm UTC](https://forum.soliditylang.org/t/making-interfaces-structural/1790/5 "2023-08-17T19:19:00Z")
+1 that overriding interfaces is redundant, and the compiler resolving diffs in interfaces by checking their definitions. At least, or until resolved, errors like shown in the screenshot below could be more explicit.. ![Screenshot_2023-08-17_at_9.08.39_AM](https://us1.discourse-cdn.com/flex001/uploads/solidity1/original/2X/5/571f67954ed5f332dbdf4cb29b8525b6c890c7ac.png)