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 term.subsetOf, term.disjoint, termlist.subsetOf, and termlist.supersetOf, which are the specific unexported functions from go/types that I adapted in https://github.com/bobg/modver/blob/go1.18/term.go.

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
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

It would help with the proposal process if someone can write down in this issue the exact function API that is being proposed

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.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group