Skip to content
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: revisit mapping of TypeNames to TypeParams #45935

Open
mdempsky opened this issue May 4, 2021 · 6 comments
Open

go/types: revisit mapping of TypeNames to TypeParams #45935

mdempsky opened this issue May 4, 2021 · 6 comments
Assignees
Milestone

Comments

@mdempsky
Copy link
Member

@mdempsky mdempsky commented May 4, 2021

When typechecking dev.go2go/src/cmd/go2go/testdata/go2path/src/chans/chans.go, go/types gives Exclusive the type:

type chans.Exclusive struct{c chan Val₁₂₆}

but its corresponding method has type:

func (*chans.Exclusive[Val₁₂₈]).Acquire() Val₁₂₈

I'm a bit surprised that Val₁₂₈ is a separate *types.TypeParam instance from Val₁₂₆. I get that it's a separate identifier with its own binding and scoping (and possibly different spelling), but I would expect the identifiers to map to the same underlying *types.TypeParam instance.

Are the separate TypeParam instances intentional/necessary? It seems a little tedious (and I'd imagine error-prone) translating between them.

/cc @griesemer @findleyr

@mdempsky mdempsky added this to the Go1.18 milestone May 4, 2021
@griesemer
Copy link
Contributor

@griesemer griesemer commented May 4, 2021

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.

@griesemer griesemer closed this May 4, 2021
@mdempsky
Copy link
Member Author

@mdempsky mdempsky commented May 4, 2021

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?

@griesemer
Copy link
Contributor

@griesemer griesemer commented May 4, 2021

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.

@mdempsky
Copy link
Member Author

@mdempsky mdempsky commented May 4, 2021

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?

@griesemer griesemer self-assigned this May 4, 2021
@griesemer griesemer changed the title go/types: methods have separate types.TypeParams from their receiver type go/types: revisit mapping of TypeNames to TypeParams May 4, 2021
@griesemer
Copy link
Contributor

@griesemer griesemer commented May 4, 2021

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

@findleyr
Copy link
Contributor

@findleyr findleyr commented May 5, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants