go/types: what is the (types.Object) identity of embedded methods?

[griesemer]

Up to Go 1.13, embedded interfaces could not have overlapping methods. The corresponding go/types implementation, when computing method sets of interfaces, reused the original methods in embedding methods. For instance, given:

type A interface {
   m()
}

type B interface {
   A
}

the go/types method Func Object for m in B was the same as in A. We know that some (external) tests depended on this property. A consequence of this is that the source position of B.m is the same as the one of A.m; it is not the position of the embedded A in B.

With Go 1.14, embedded interfaces may overlap. The same method m (with identical signature), may be embedded in an interface through multiple embedded interfaces:

type C interface {
   A
   A2  // A2 also defines m()
   A3  // A3 also defines m()
}

Now, it is not clear which "original" method m should be used in the method set for C. It could be the "first" one (as in the one embedded via the earliest embedded interface providing m in the source, so A in this example), or it could be undefined. Or it could be a new method Func Object. Note that the latter choice wouldn't be of much help when deciding which position should be assigned to m as it could be any of the embedded interfaces that provide m.

This boils down to what kind of API guarantee should be provided by go/types.

[gopherbot]

Change https://golang.org/cl/196561 mentions this issue: go/types: don't clone interface methods when embedding them

[griesemer]

@alandonovan, @katiehockman do you have any opinion on this?

[adonovan]

The crucial property is that it is deterministic: a lookup of C.m must return the same object each time. I don't think we need to guarantee that it is identical to A.m or A2.m or A3.m; an implementation could use lexical order, lexicographic order, or any other order.

What matters for most interface operations is the set of methods, not the identities of the method objects. interface{f()} is identical to interface{f()} no matter how many times you write out a new declaration of f and thus create a new Object.