proposal: go/types: Create a public CoreType() function

[nevkontakte]

Core types is a first-class concept in the Go Spec, which was introduced with type parameter support. go/types is the official package for tooling developers to interact with type information for Go programs, but it doesn't offer a public API to determine a core type. As a result, this logic has been reimplemented multiple times by independent parties [1, 2, 3], which isn't ideal for obvious maintenance reasons.

Proposal: Make the currently unexported coreType() implementation in go/types exported for everyone to use.

[ianlancetaylor]

CC @griesemer @adonovan

[griesemer]

cc @findleyr

[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.

[nevkontakte]

@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.

[findleyr]

@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.

[findleyr]

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.

[adonovan]

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.

[timothy-king]

(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.

[timothy-king]

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).