As far as a.Worker and b.Worker not being identical, the relevant section of the spec is:
https://golang.org/ref/spec#Type_identity *Two interface types are identical if they have the same set of methods > with the same names and identical function types. Lower-case method names > from different packages are always different. The order of the methods is > irrelevant* The two interfaces do not have the same function types; they are, respectively Work(arg a.Arg) // for a.Worker and Work(arg b.Arg) // for b.Worker hence the two interfaces are not identical. Your example with c.Arg works because the function types are now identical (if I've understood your follow up email correctly) I think, and apologies if I'm getting the wrong end of the stick here, the confusion is arising because of perceived overlap with other areas of the spec: https://golang.org/ref/spec#Assignability https://golang.org/ref/spec#Interface_types Hopefully this helps but please say if not. On 10 March 2017 at 13:01, Henry <[email protected]> wrote: > Let's suppose a.Worker and b.Worker both have method Work(c.Arg) where > c.Arg is a struct instead of an interface. The compiler now recognizes both > a.Worker and b.Worker as identical although both live in different > packages. The code will compile just fine. > > I don't think it matters where the type lives. My understanding is that > the intent of Go's interface to allow substitution of any type as long as > the type satisfies the required method signatures. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
