This is intentional. Each method declares its own type parameters. Also, methods are not instantiated when a type is instantiated (to avoid all kinds of problems with cycles). They are instantiated when the method is looked up.

There may be better implementation strategies down the road, but at least this is not a bug.

This is intentional. Each method declares its own type parameters.

It's a bit ambiguous to me what you mean here, since there's the Object vs Type distinction within go/types. Specifically, I'm suggesting that methods on parameterized receiver types should still have their own TypeName instances, but these should point to the same TypeParam as the receiver type's declaration uses. Similar to how type aliases work.

Also, methods are not instantiated when a type is instantiated (to avoid all kinds of problems with cycles). They are instantiated when the method is looked up.

Can you elaborate on how type instantiation is relevant here? E.g., if Exclusive.Acquire used Val₁₂₆ directly instead of Val₁₂₈, at lazy instantiation time isn't it just a matter of substituting a different variable?

To clarify: Each method declares its own TypeName objects (one per type parameter) which are in a 1:1 correspondence to their own local type parameters. It may be possible for TypeName objects to share corresponding type parameters - I don't know and haven't focussed on it - I am just stating that this is the current implementation. The best representation of type parameters is something that I think we're still learning about.

The comment on instantiations of methods is unrelated. I just mentioned it as an additional thing that is "not coupled" with the receiver type.

Ack that this is currently working as intended, and it's not urgent to change (or even necessarily desirable). But as a user-visible detail of the go/types API, it does seem like something we want to consider before Go 1.18. That's why I filed this issue: I think this might be a worthwhile way to simplify/improve the API, and I wanted to make sure it's on our radar when the time comes to consider tweaks like this.

Is there somewhere else to track API feedback?

Ack that this is user-visible and may need a revisit.

Is there somewhere else to track API feedback?

I'm going to file issue(s) soon for the go/ast and go/types API changes, though to be honest this wasn't on my radar. Let's keep this issue open, and I can reference it in the go/types API proposal.

@findleyr Is there anything left to do here? (If not, please close.) We're not going to change the mapping at this point (and we already moved from lists of TypeNames to lists of TypeParams internally, which was an improvement).

Agreed, I don't think there's anything to do here.

In particular, it has proven useful to have a bijection of TypeName<->TypeParam (via the .Obj() method), similar to Named. This would not be possible if the multiple TypeNames referred to the same TypeParam.

I've run into this myself. I understand that the current implementation may be useful, but I'm wondering what is the intended method of mapping between these separate TypeParam instances if a tool wants to union their references.

Type parameters have an index (go/types.TypeParam.Index()) which identifies them. We are also considering providing an "owner" (the object which declares them).

cc: @findleyr in case he wants to add something

As @griesemer said, Index() is the way to do the join.

@schroederc can you say more about what you're trying to do? It would help us to understand your use-case.

I'm working on adding support for generics to the Kythe indexer that provides xrefs for CodeSearch.

Looks like that API is still in flux: https://github.com/golang/go/blob/master/src/go/types/typeparam.go#L54. Is there an ETA or a bug I can subscribe to for updates?

Oh, that was an oversight. I thought Index was exported.

https://golang.org/issue/47916 is the tracking bug.

Slight correction: I remember now that we intentionally held off on exporting Index, with the assumption that it would always be apparent from the surrounding code. It sounds like that's not the case for you. I see no harm in exporting it.