Repository navigation
Reconsider or clarify the "No Interfaces" directive to allow for compiler generated ERC165 interface IDs. #38
Description
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?
Activity
mudgen commentedon Oct 20, 2025
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.
cyotee commentedon Oct 20, 2025
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.
mudgen commentedon Oct 21, 2025
That is correct. No interface inheritance for now.
maxnorm commentedon Oct 21, 2025
Hi, @mudgen & @cyotee, i suggest opening a new github discussion thread instead of a issue for now.
I will close the issue if it's ok with y'all
mudgen commentedon Oct 21, 2025
I am converting this to a discussion.