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: expose an API for normalized interface terms #61013

Open
findleyr opened this issue Jun 26, 2023 · 6 comments
Open

go/types: expose an API for normalized interface terms #61013

findleyr opened this issue Jun 26, 2023 · 6 comments
Assignees
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@findleyr
Copy link
Contributor

This is a placeholder for planning purposes, to be exchanged for a proper proposal at a future date.

As discussed in #60994, there are some missing go/types APIs that are currently papered over with the x/exp/typeparams package.

In particular, we should propose a go/types API that serves the purpose of the NormalTerms function -- some way to traverse a normalized representation of the terms of an interface types.

We could expose an equivalent API to NormalTerms, or do something simpler. Let's decide early in the go1.22 cycle.

CC @griesemer @adonovan @timothy-king @mdempsky

@findleyr findleyr added this to the Go1.22 milestone Jun 26, 2023
@findleyr findleyr self-assigned this Jun 26, 2023
@findleyr findleyr added the early-in-cycle A change that should be done early in the 3 month dev cycle. label Jun 26, 2023
@timothy-king
Copy link
Contributor

Might be helpful to go over what x/tools/go/ssa uses. The heaviest usage of NormalTerms is indirect via x/tools/internal/typeparams.CoreType. If we only release NormalTerms, CoreType will be the performance sensitive path. Other uses of NormalTerm go through the function x/tools/go/ssa.typeSetOf. The use of this is somewhat varied. FWIW all uses only pay attention to the underlying types in the list.

@gopherbot
Copy link
Contributor

This issue is currently labeled as early-in-cycle for Go 1.22.
That time is now, so a friendly reminder to look at it again.

@findleyr
Copy link
Contributor Author

findleyr commented Nov 7, 2023

Unfortunately, this isn't going to happen for 1.22, which is perhaps not unreasonable given #63940. Let's wait another cycle to see if the correct API emerges.

@findleyr findleyr modified the milestones: Go1.22, Go1.23 Nov 7, 2023
@gopherbot
Copy link
Contributor

This issue is currently labeled as early-in-cycle for Go 1.23.
That time is now, so a friendly reminder to look at it again.

@findleyr
Copy link
Contributor Author

I still think we should do this, but it's been an unfortunately low priority as most users have access to terms via x/tools/internal or x/exp/typeparams.

Moving to the backlog, as it seems unlikely that we'll take this on before there is more demand. As mentioned above, #63940 is a higher priority for the team, and may affect the design of this API.

@findleyr findleyr removed the early-in-cycle A change that should be done early in the 3 month dev cycle. label May 14, 2024
@findleyr findleyr modified the milestones: Go1.23, Backlog May 14, 2024
@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 13, 2024
@findleyr
Copy link
Contributor Author

findleyr commented Aug 6, 2024

@timothy-king as you are working on go/types and have a lot of experience with core types / normalized interface terms from your work on go/ssa, you seem like the perfect person to design a nice API here :)

Tentatively reassigning, though I will leave it to you to prioritize.

@findleyr findleyr assigned timothy-king and unassigned findleyr Aug 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants