Many constant expressions only have "untyped" types. For example, const k = 0. For those, go/types records an untyped type.

In other cases, a constant expression is used in a context that implies a "true" (runtime) type. For example strings.Repeat("", 1) implicitly converts "" to string and 1 to int. In those cases, go/types already applies the contextually implied conversion to the constant, so the types of the literals are records as string and int, respectively. (You can verify this in the types playground.)

(Aside: I vaguely recall requesting this behavior a long time ago, but have since come to regret doing so as it makes it harder when analyzing typed syntax to notice implicit conversions. At least prior to generics, there were very few places where type information flowed top-down: only shifts, IIRC.)

So I'm not sure exactly what change this issue is asking for.

I think a better way to state my request would be that go/types should only assign "untyped" types to constant expressions. Any non-constant expression should have an assigned non-untyped type.

The linked to code mentions several cases where go/types assigns "untyped" types to non-constant expressions:

Funny, Rob sent me a CL today that introduced me to your unconvert tool, a comment in whose source led me to
#13061, in which you argue for keeping constants as untyped.

Oh, just hedging my proposals I suppose.

I think this is fine and I was planning to do this, a few years in the past, if I recall correctly. But we ended up not doing it because (I'm not sure anymore) some backward-compatibility or other issues.

We should perhaps try again, and if need be introduce a flag to control the behavior.