proposal: spec: represent interfaces by their definition and not by package and name

[metakeule]

An interface is a collection of method names and signatures.

Say, we have:

package a

type Writer interface {
    Write([]byte) (int, error)
}


type WriterTo interface {
     WriteTo(Writer) (int64, error)
}

type WriterTo2 interface {
    WriteTo(w interface{Write([]byte) (int, error)} (int64, error)
}


From the perspective of the one writing an implementation, the a.Writer
and io.Writer are the same: As long as the Write method has the right
signature they are both fulfilled. 

However a.WriterTo and io.WriterTo are not, simply because they refer
to Writers of different packages although they have the same definition. Even WriterTo2
would only be compatible with io.WriterTo if
they later had an anonymous interface too.

see http://play.golang.org/p/kOH11TOlsE

Since interfaces are all about reusable code this behaviour must be 
considered an artifact of the way, interfaces are represented and treated during
compilation.

Since interfaces have no methods and no values, their only value is to help the
programmers via the type constraints. 

From the implementation perspective a.WriterTo, io.WriterTo and a.WriterTo2 must be
treated as being the same, a contraint to have a method WriteTo(w
interface{Write([]byte) (int, error)} (int64, error).

The names (and packages) of the interfaces should not be relevant for the compiler.
Instead the definition should be the representation and the names just shortcuts to
refer to them.

[ianlancetaylor]

Comment 1:

Labels changed: added go2, languagechange, repo-main, release-none.

Status changed to LongTerm.

[griesemer]

Comment 2:

See also issue #8691.

Status changed to Thinking.

[gopherbot]

Comment 3 by toddw@google.com:

While admittedly this issue comes up rarely in regular code, as a data point, I run into
this issue quite a bit.  I've built an RPC stub compiler that takes an API specified in
my own language, compiles it, and then generates RPC stubs in different languages.  Go
is the core generated language.
As a simplified example, let's say the user tells me to generate stubs for a RPC
function "Print" that streams int32 from client to server, and streams strings from the
server back to the client.  Here's the Go API that I generate for the user on the client
side.
type PrintClientStream interface {
    // SendStream returns the send side of the client stream.
    SendStream() interface {
        Send(item int32) error // Places an item on the output stream
        Close() error // Indicates no more items will be sent
    }
    // RecvStream returns the receiver side of the client stream.
    RecvStream() interface {
        Advance() bool // Stages an item to be retrieved via Value
        Value() string // Returns the staged item
        Err() error // Returns errors
    }
}
Obviously the choice of "int32" and "string" are up to the user, as is the RPC function
name.  The reason SendStream() and RecvStream() return anonymous interfaces is because
of this issue.  A client may need to use two different services that define different
APIs, but result in the same streaming types; client sends int32 and receives string. 
I'd like them to be able to write a single function that operates over the two different
PrintClientStream interfaces.  But if I named the return types from SendStream and
RecvStream, they'd lose this ability.
I also have a straw man proposal.  
I understand the concepts of type identity and assignability as defined in the language
spec:
http://golang.org/ref/spec#Properties_of_types_and_values
I also appreciate the consistency of the current type identity rules wrt named types: a
named and an unnamed type are always different.  Whenever you see a "type" declaration
in a source file, you know that a distinct type is being defined.
Let's say we changed the language spec to say that type identity for interfaces ignores
the name.  I.e. interface names are simply a convenient shorthand, but for type identity
purposes, it's as if every interface were anonymous.  The rules for comparing these
interfaces remains the same; it's an order-agnostic comparison of method names and their
function types, and unexported methods in different packages are always different.
I think this is a nice and consistent way to specify this feature.  The main downside I
see is that it's yet another special-case in the language spec.  But interfaces are
already special; we already have the special-case in our value assignability rules.
<wishful thinking>
If you haven't tuned out so far, here's a thought.  Why wait until Go2 to incorporate
this feature?  My rationale: it seems unlikely that anyone was actually relying on the
existing semantics.  After all the compiler has ensured that all static type checks obey
the existing rules, and we're simply relaxing those rules so that more cases are allowed.
But for full disclosure, I do recognize that if we change this in Go1, existing code can
notice a change in behavior.  After all we provide type assertions in the language, as
well as the reflect package.  E.g.
http://play.golang.org/p/OscKQCdDOL
That's where my wishful thinking comes in.  I can't think of a reasonable way someone
would be using the existing semantics; my assertion is that if they're relying on
something this subtle, their code deserves to be broken (and I'm only half-kidding). 
But I can see that if we strictly follow the Go 1 compatibility rules, we simply cannot
change this feature, regardless of how much the code that relies on this deserves to be
broken.
Thoughts?

[maxnordlund]

This reminds me of the strawman to add typed objects to JavaScript, which considers two struct types equivalent iff they have the same fields (name and type) in the same order.

[mattn]

I'm thinking main.Writer should be treated as different as io.Writer. Because WriterTo have different signature of argument. I prefer to use embed interface of io.Writer in this case.

http://play.golang.org/p/IklkWaIvWG

[metakeule]

@mattn I want to be able to write a function that can receive any of the WriterTo interfaces.

[evanphx]

A quick note on this issue for anyone that is still watching it: Go "does the right thing" if the 2 inner interfaces are declared anonymous. That means the compiler and runtime already support the ability to do the right thing, it's just being overly strict if the interface has a name. Seems that a simple change, to ignore any given name when type checking 2 interfaces, would easily solve this issue.