go/types: add Object.Origin [freeze exception]

[findleyr]

I propose to add the following methods to types.Var and types.Func:

// Origin returns the canonical object for its receiver, i.e. the object
// recorded in Info.Defs.
//
// For instantiated variables Origin returns the type-parameterized object from
// which the receiver was created. For all other variables Origin returns the
// receiver.
func (obj *Var) Origin() *Var 

// Origin returns the canonical object for its receiver, i.e. the object
// recorded in Info.Defs.
//
// For instantiated functions Origin returns the type-parameterized object from
// which the receiver was created. For all other functions, Origin returns
// receiver.
func (obj *Func) Origin() *Func

While instantiating types, we necessarily have to create instantiated copies of their methods/fields/parameters/etc. However, as we work on updating tools for generics, an emerging theme is that is useful to be able to answer the following two questions:

1. Is this object canonical?
2. What is the canonical object corresponding to this object?

Right now, these are not easy questions to answer. For methods, these can be answered by a lookup on the receiver base origin type. For fields / parameters / etc., it is more difficult and may require finding the relevant *ast.Ident and looking in Info.Defs.

Adding an Origin method to these types answers both of these questions trivially, at the cost of a pointer per object. If the added memory is a concern, there are several internal fields on types.object used during type-checking that may be externalized to free memory.

CC @griesemer @dominikh @timothy-king @mdempsky

[griesemer]

Does it make sense to have Origin on each Object? Isn't it sufficient to have it for TypeNames and Funcs?

[findleyr]

Isn't it sufficient to have it for TypeNames and Funcs?

We'd need it for Vars as well (and technically we don't need it for TypeNames: we don't expose any non-canonical TypeNames). When we instantiate structs / signatures, we instantiate vars.

[timothy-king]

Do we want more experience with the existing alternatives available before making a decision?

[findleyr]

Do we want more experience with the existing alternatives available before making a decision?

It's fine to wait if we think we'll get more signal, but I do think we should add something for 1.19. This feels like a philosophical oversight: the canonical nature of Objects was broken without an API to easily 'canonicalize'.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[findleyr]

We'd need it for Vars as well (and technically we don't need it for TypeNames: we don't expose any non-canonical TypeNames). When we instantiate structs / signatures, we instantiate vars.

I think it would be fine to simply add Origin to the objects that could possibly be instantiated: Var and Func, I think. That is more conservative, and we can always add it to the Object interface later.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

[griesemer]

@findleyr The more conservative approach seems fine. Can you please send out a CL soon so we can see the implications in detail?

[gopherbot]

Change https://go.dev/cl/395535 mentions this issue: go/types: set an origin object for vars and funcs

[findleyr]

https://go.dev/cl/395535 contains a prototype of the new API, which is added only to *Func and *Var.

A notably questionable decision: I opted to have the new methods return Object, even though they could return *Func and *Var, respectively, to leave open the possibility that this API is added to the Object interface in the future. By comparison, (*Named).Origin returns *Named, so maybe we should opt for the more specific results. ...as I write this I am thinking that returning concrete types is probably this is the better option, but I would pose the question to the audience in any case.

[dominikh]

I'm leaning towards returning Object. Even without the API being added to Object, users can define their own interface and get the origin object with a single type assertion/call. (*Named).Origin returning *Named doesn't seem problematic, since Named isn't an Object and thus isn't technically part of the same API.

[rsc]

Moving back to active to resolve the discussion about the result type.

[findleyr]

Discussed this with @griesemer, and it seems like the arguments for concrete result types are compelling:

• Fewer type assertions at the call site.
• Less likely to introduce a typed nil.

On the other hand, we wouldn't be able to pass around interface{ Origin() Object } as @dominikh suggests, but it would of course be easy to write a helper func originObject(Object) Object.

By way of analogy, we document that Type() of a *Func is always *Signature, yet I have seen many places in x/tools where we use a commaok type assertion and handle the case that the Type() of a *Func is not a *Signature. I would guess that returning Object will lead to similar misuse.

[rsc]

@findleyr, thanks for updating the top comment with the proposed API. Does anyone object to this change?

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

[findleyr]

CC @adonovan :)

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

[findleyr]

CC @golang/release

This issue was filed early in the dev cycle, but due to ongoing discussion and the abbreviated cycle, was not accepted until a few days before the freeze. With other priorities in go/types (particularly the urgent https://go.dev/issue/52715), I didn't get to the implementation of this feature before the freeze.

I'd like to request a freeze exception to land this proposal for 1.19, as it allows us to redefine a 'canonical' invariant that was broken with generics. Certain types of static analysis (such as dominikh/go-tools#1215 or some Google-internal analyses) would be facilitated by these new APIs.

Please let me know if you'd like me to file a new issue for the freeze exception request, or if you need any other information to help make a determination.

[cagedmantis]

This freeze exemption has been approved. Nothing else is required for the exemption request.

[findleyr]

Thanks all!