> > Thanks for the reply. I will rephrase the question. See the code > illustration in the first post if you did not follow the discussion from > the beginning. >
Indeed, I've been following since you first posted so I saw that illustration. > a.Arg and b.Arg are identical interfaces living in different packages: > package a and package b respectively. Type X that implements a.Arg is > automatically assignable to b.Arg. In fact, you can use X as a parameter > to either Work(a.Arg) and Work(b.Arg) without any problem. This implies > that a.Arg and b.Arg are identical from assignability perspective and the > compiler can recognize this. However, the compiler does not think > Work(a.Arg) and Work(b.Arg) as identical even though a.Arg and b.Arg are > identical (assignable to each other). a.Worker interface that has > Work(a.Arg) is not assignable to b.Worker interface that has Work(b.Arg). I > wonder why. > There is an old golang-nuts thread on a related topic (that I can't find), a topic that is highlighted by this example: https://play.golang.org/p/ZNKfmhEl_f In the thread, I seem to recall Rob Pike (?) explaining the rationale behind the decision to require exact type signature matching for interface implementation as being: simplicity of specification and understanding, and compiler speed. I understand the point you're making and should have made that clear in my previous post, but this is not, to my understanding (and please someone correct me if I'm wrong on the history/rationale here), how Go has been designed and specified as a language. Other languages may, and indeed do, differ on this point. Paul -- 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.
