Hi,
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.
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.
Let's make the example more realistic.
package a
type Formatter interface{
Format(input []byte) []byte
}
type Writer interface{
Write(raw []byte, formatter Formatter) error
}
func NewWriter() Writer{
//...
}
then in package b
package b
type Formatter interface{
Format(input []byte) []byte
}
type Writer interface{
Write(raw []byte, formatter Formatter) error
}
func NewWriter() Writer{
//...
}
then in the main package
package main
type Formatter interface{
Format(input []byte) []byte
}
type Writer interface{
Write(raw []byte, formatter Formatter) error
}
func main(){
var writers []Writer
writers = append(writers, a.NewWriter()) //Compile failure: a.NewWriter
does not implement Write([]byte, main.Formatter) error
writers = append(writers, b.NewWriter()) //Compile failure: b.NewWriter
does not implement Write([]byte, main.Formatter) error
}
I do think that ideally the compiler should be able to recognize
main.Writer, a.Writer, and b.Writer as assignable to one another.
On Friday, March 10, 2017 at 8:55:54 PM UTC+7, Paul Jolly wrote:
> 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] <javascript:>>
> 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] <javascript:>.
>> 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.
