I agree that the event should be recommended instead of required, but I think the functions should be mandatory. It is possible I am wrong because I haven’t thought too much about it. I think after some discussion we will agree.
This topic opens an important philosophical discussion about what an interface should contain and what it should not.
First, I’ll describe my notion of compatibility to distinguish it from both inheritance and a more vacuous definition. Compatibility means “able to exist or occur together without conflict”. What makes ERC 2535 and ERC 8153 compatible with ERC 8167 is not inheritance or universal support, but that the interface is not especially burdensome or contradictory. Duplicative events (e.g. FacetAdded and DelegateSet) are somewhat burdensome for gas but don’t force a particular data structure or algorithm. Duplicative methods (e.g. facetAddress and implementation) aren’t burdensome for runtime gas but do require deploying code that can read your data structure. In contrast, ERC-1538 is incompatible with ERC-8153 because ERC-1538 uses strings to surface ABI while ERC-8153 gets its ABI from its facets but those facets aren’t required to provide such strings.
Second, ERC-8167 is a good common base interface because it does not prescribe a particular data structure, and because it does enforce unnecessary requirements. What MUST means is that if you don’t have it, you aren’t in compliance. It’s important to standardize how block explorers surface the ABI. Just specifying that some combination of methods can perform similar actions is not helpful to consumers of the interface. A similar argument can be made about events, but I recognize the gas and codesize costs of log redundancy. The official standard for these imperatives is:
In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
This interoperability standard is the criterion by which I argue the two functions should be REQUIRED. However I concede that the DelegateSet event is less important and can be demoted.
Third, why should things ever be RECOMMENDED or OPTIONAL when they can be removed entirely? They are good for harm reduction and for outlining best practices. I feel this way about the error FunctionNotFound because revert data is usually bubbled up, because error handling is so rare, and because on-chain handling of this particular error is unexpected. If the error handling were an important part of the interface, this error would be required. Similarly, there are circumstances where the DelegateSet event may be unnecessary, for example if there were a redundant and more informative event, such as the ones specified in ERC-8153. This is also why selectors() was recommended: there may be superior but noncompliant ways to surface the ABI.
In conclusion:
selectors()meets both the interoperability and non-conflict standards and so should be promoted to REQUIRED. Any modular dispatch proxy that can surface its entire ABI can implement this method at no additional runtime cost.implementation(bytes4)meets both the interoperability and non-conflict standards and so should remain REQUIRED. Any modular dispatch proxy has to be able to calculate this in order to delegate so is existence should not impose any additional runtime cost.DelegateSet(bytes4,address)meets neither the interoperability standard nor the non-conflict standard, but because of both its importance in auditing and the viability of good alternatives, it should be demoted to RECOMMENDED.FunctionNotFound(bytes4)has informational importance, and some error has to be returned anyway, but there may be superior alternatives and backwards compatibility challenges, so it should remain RECOMMENDED.
Your opinion on this is important to me, so let me know if you agree with these changes and the larger framework supporting them.