You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The proposal is to allow interfaces to have non-unique names as long as the method signature is identical for all methods with the same name, that is, to allow duplicate methods. Type Dup above would be allowed, but type NotDup would not. For the purposes of type identity, interface satisfaction, etc., duplicate methods in an interface would be treated as if they occurred exactly once.
This arises in practice when embedding interfaces. Consider:
typeAIinterface {
A()
}
typeBIinterface {
AI
}
typeCIinterface {
AI
}
typeDIinterface {
BICI
}
Type DI is disallowed by the spec, even though it may be the most clear, concise, self-documenting, easy to maintain, DRY way to express the interface. To work around this, users must manually duplicate the contents of the interface.
This invites the response "just write the code!". But it is worth observing that these duplicated interfaces can be large and can occur spread across multiple levels and across multiple packages with multiple owners. More importantly, when changing one of the embedded interfaces, all copies must be changed, and there is no clear way to write a tool to safely do that, or even detect a problem, because the explicit link between the embedding and the embedded interface is gone.
I believe that the update to the spec would be minimal, and that the impact on compilers and typecheckers would be small and localized.
cc @hasty who has been repeatedly frustrated by this
This is a proposal for a minor, backwards-compatible language change.
Currently, all methods in an interface type must have different names. The spec says:
This means that both these interfaces are disallowed:
The proposal is to allow interfaces to have non-unique names as long as the method signature is identical for all methods with the same name, that is, to allow duplicate methods. Type Dup above would be allowed, but type NotDup would not. For the purposes of type identity, interface satisfaction, etc., duplicate methods in an interface would be treated as if they occurred exactly once.
This arises in practice when embedding interfaces. Consider:
Type DI is disallowed by the spec, even though it may be the most clear, concise, self-documenting, easy to maintain, DRY way to express the interface. To work around this, users must manually duplicate the contents of the interface.
This invites the response "just write the code!". But it is worth observing that these duplicated interfaces can be large and can occur spread across multiple levels and across multiple packages with multiple owners. More importantly, when changing one of the embedded interfaces, all copies must be changed, and there is no clear way to write a tool to safely do that, or even detect a problem, because the explicit link between the embedding and the embedded interface is gone.
I believe that the update to the spec would be minimal, and that the impact on compilers and typecheckers would be small and localized.
cc @hasty who has been repeatedly frustrated by this
cc @griesemer @ianlancetaylor @rsc @robpike @mdempsky @bradfitz to tell me why this is a terrible idea :)
The text was updated successfully, but these errors were encountered: