CC @griesemer @adonovan

cc @findleyr

Thanks. IIRC the only reason we didn't expose this function originally is that we weren't quite sure what the API should be (and there was a lot of new API in 1.18). The x/exp/typeparams.NormalTerms API was meant as a placeholder, but we never proposed an API for go/types. Thanks for prodding us in the right direction.

We definitely should have an API for the this operation of reducing type sets, because otherwise libraries like x/exp/typeparams have to maintain a copy of this tricky logic. However, I'm not sure that CoreType is sufficient. I suspect that static analysis tools such as analyzers in x/tools/go/analysis or staticcheck will need to access a normalized form of the type set, as provided by the NormalTerms API.

Therefore, +1 to this proposal, but I think we should bundle it with an additional API that exposes the normalized representation of the type set.

@findleyr thanks for the response. I am currently implementing generics support in gopherjs and CoreType() is the only missing API I ran into so far. I am only half way through the project though, so it's possible that I'll need normalized type sets would be needed at some point.

@nevkontakte for something like a compiler I think CoreType may be sufficient.

For analyses (e.g. the printf analyzer), we need to be able to ask questions like "is this true for all/any types in the type set". We should expose APIs that can answer these questions.

But there is no question in my mind that we should have a CoreType function, since as you point out this is a feature of types defined in the spec.

I opened #61013 to track an API for interface terms. I don't want that to distract from this proposal, which can be decided independently.

I agree that we should export CoreType. But unlike Underlying it may return nil, which is quite a subtlety that needs to be at least documented clearly. Does it warrant a (Type, bool) result to force callers to consider this case? I tend to think not.

(Type, bool) What would the bool mean? Type set does not have a core type? This seems redundant with nil. Type set is empty? Type set is >= 2 reconcilable types? That is useful information, but maybe too niche.

If we export CoreType(), we probably need to decide on a representation for bytestring which is both a core type and has a type set size of 2 (https://go.dev/ref/spec#Core_types).