-
Couldn't load subscription status.
- Fork 18.4k
Closed
Labels
FrozenDueToAgeLanguageChangeSuggested changes to the Go languageSuggested changes to the Go languageNeedsDecisionFeedback is required from experts, contributors, and/or the community before a change can be made.Feedback is required from experts, contributors, and/or the community before a change can be made.ProposalProposal-Acceptedv2An incompatible library changeAn incompatible library change
Milestone
Description
If you view an interface as a set of constraints on the implementing type, then
combining two interfaces (that are not mutually incompatible) such as:
type I interface { f(); String() string }
type J interface { g(); String() string }
has a natural interpretation that is equivalent to an interface containing the union of
such constraints. e.g. these should be equivalent:
type IJ interface { I; J }
type IJ interface { f(); g(); String() string }
but in fact the first is an error: "duplicate method: String". This is
somewhat surprising. Is there any reason not to permit this? The set-union behaviour
is easy to understand, describe and implement, and it seems useful in practise when you
have overlapping interfaces describing different aspects of a type.
(I chose String() string since I've seen many users add this constraint to their
interfaces. It could be any method though.)dsnet, cespare, leighmcculloch, prashantv, griesemer and 111 moreKonstantin8105, doylecnn, toukii and josephGuogocs
Metadata
Metadata
Assignees
Labels
FrozenDueToAgeLanguageChangeSuggested changes to the Go languageSuggested changes to the Go languageNeedsDecisionFeedback is required from experts, contributors, and/or the community before a change can be made.Feedback is required from experts, contributors, and/or the community before a change can be made.ProposalProposal-Acceptedv2An incompatible library changeAn incompatible library change