Repository navigation
Reconsider or clarify the "No Interfaces" directive to allow for compiler generated ERC165 interface IDs. #38
Description
Activity
Compose is going to needs to have interfaces for the reason you mention and to interoperate with ERC standards and other contracts.
I am not sure yet if we should allow contracts to inherit interfaces, because so far the name of a contract and documentation about it should say what it implements, and inheriting interfaces adds a bit of complexity and I am trying remove every bit complexity we can. So for now we are not inheriting interfaces.
Not inheriting is fine. Inadvisable, because you have no assurance that a facet correctly implemented an interface. And it is possible to reduce complexity to a degree you cause problems.
It's easy to mandate the devs can't use @inheritdoc as a contribution guideline while allow interface inheritance so we get compiler compliance checks. A custom linter rule could enforce that in the CI pipeline.
no assurance that a facet correctly implemented an interface. And it is possible to reduce complexity to a degree you cause problems.
That is correct. No interface inheritance for now.
I am converting this to a discussion.
- locked and limited conversation to collaborators
on Oct 21, 2025
ERC-2535 states Diamond's may expose ERC-165. Even stating how the IDiamondCut interface ID is calculated.
Solidity now computes ERC165 interface IDs for you with type(Interface).interfaceid.
How does the "No Interfaces" directive relate to this? May contributions include interfaces to use the computed interface ID? Does the directive only relate to inheriting interfaces into contracts? And, is there a reason for the limitation beyond just not being relevant to deployed code and conforming with the no inheritance directive?