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 · 4 comments
Open

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

findleyr opened this issue Jun 26, 2023 · 4 comments
Assignees
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle.
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

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle.
Projects
None yet
Development

No branches or pull requests

3 participants