-
Notifications
You must be signed in to change notification settings - Fork 17.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
go/types: what is the (types.Object) identity of embedded methods? #34421
Comments
Change https://golang.org/cl/196561 mentions this issue: |
@alandonovan, @katiehockman do you have any opinion on this? |
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. |
https://golang.org/cl/191257 significantly changed (and simplified) the computation of interface method sets with embedded interfaces. Specifically, when adding methods from an embedded interface, those method objects (Func Objects) were cloned so that they could have a different source position (the embedding position rather than the original method position) for better error messages. This causes problems for code that depends on the identity of method objects that represent the same method, embedded or not. This CL avoids the cloning. Instead, while computing the method set of an interface, a position map is carried along that tracks embedding positions. The map is not needed anymore after type- checking. Updates #34421. Change-Id: I8ce188136c76fa70fba686711167db29a049f46d Reviewed-on: https://go-review.googlesource.com/c/go/+/196561 Reviewed-by: Matthew Dempsky <[email protected]>
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:the
go/types
methodFunc
Object
form
inB
was the same as inA
. We know that some (external) tests depended on this property. A consequence of this is that the source position ofB.m
is the same as the one ofA.m
; it is not the position of the embeddedA
inB
.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:Now, it is not clear which "original" method
m
should be used in the method set forC
. It could be the "first" one (as in the one embedded via the earliest embedded interface providingm
in the source, soA
in this example), or it could be undefined. Or it could be a new methodFunc
Object
. Note that the latter choice wouldn't be of much help when deciding which position should be assigned tom
as it could be any of the embedded interfaces that providem
.This boils down to what kind of API guarantee should be provided by
go/types
.The text was updated successfully, but these errors were encountered: