-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
proposal: go/types: export term/termlist logic #50963
Comments
Hi @bobg, would #50447 satisfy your needs? I am hoping to mail a CL for this package this week (though it will take some time to review). We will add an API to go/types for type sets, probably in 1.19. CC @griesemer |
Thanks @findleyr! It doesn't look like it will entirely suffice. Unless I'm mistaken, it doesn't include ways to call On the other hand, it looks like InterfaceTermSet might do the same job as my termsOf function, and possibly more correctly. 👍 |
It would help with the proposal process if someone can write down in this issue the exact function API that is being proposed. That is, function declarations and doc comments, but without the actual code. Thanks. |
This proposal has been added to the active column of the proposals project |
This is just a suggestion, there are probably other good ways to expose the same functionality. // IsTermListSubset reports whether the terms in u constitute a subset of the terms in v.
// The result is true whether u is a proper or an improper subset of v (i.e., if they are equal).
// The order of the items in u and v is unimportant.
// The second and subsequent occurrences of any item in either slice is ignored.
// A term T is a subset of a term ~T.
func IsTermListSubset(u, v []*types.Term) bool This is the only entrypoint that my package modver needs (assuming we're also getting the API proposed in #50447), but there are several related functions that the community might find useful. |
Incidentally, should modver be added to #50558 ? |
We are not settled on the internal representation here, which is why it's not exported yet. For now, it seems like we should continue not to export it. Eventually we will export things, but the right answer for tools that need something today is to make a copy of the package and adapt it as needed. |
Going to mark this likely decline, with the caveat that we will return to appropriate generics-related new API in a future release. |
Based on the discussion above, this proposal seems like a likely decline. |
No change in consensus, so declined. |
I have been making https://github.com/bobg/modver generics-aware. This package can compare two versions of a Go module and tell whether a major, minor, or patchlevel version-number bump is needed, according to semver rules. (I previously wrote about this in #50646.)
In order to compare two interface types containing type unions, I found it necessary to duplicate some unexported logic from go/types. See my work in progress here: https://github.com/bobg/modver/blob/go1.18/term.go
It would be useful, and simple, to export those functions, adding them to the go/types API.
The text was updated successfully, but these errors were encountered: