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.)
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.)