go/types, types2: type checker accepts invalid program

[griesemer]

Per the spec:

In an alias declaration the given type cannot be a type parameter.

thus, the following code is invalid, yet the type checker accepts it (playground):

type A[P any] = P

[griesemer]

The same restriction exists also for type definitions (non-alias type declarations).
Perhaps the restriction can be removed for alias types (to be investigated), but for now the compiler/typecheckers should follow the spec.

[gopherbot]

Change https://go.dev/cl/711423 mentions this issue: go/types, types: RHS of alias declaration cannot be a type parameter

[gabyhelp]

Related Issues

• go/types: TypeName.IsAlias reports true for type parameters #49213 (closed)
• types2: invalid program crashes types2 #47996 (closed)
• go/types: erroneously accepts recursive type aliases #25141 (closed)
• cmd/compile: type arguments for generic aliases are not checked against type parameter constraints #69576 (closed)
• go/types, cmd/compile/internal/types2: disallow type parameters as RHS of type declarations #45639 (closed)
• go/types, types2: bad "invalid composite literal type" error for type parameter with pointer structural type #50833 (closed)
• cmd/go2go: Type aliases of generic types fail to compile #39768 (closed)
• types2, go/types: declaring methods on instantiated types through an alias type should not be permitted #47968 (closed)
• types2, go/types: self-referential type parameter list is not accepted #47796 (closed)
• go/types, types2: alias types are restricted to basic interfaces, should allow arbitrary interfaces #51616 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[findleyr]

We should land this fix now, but also try to land #75885 for 1.26, since there is likely to be user code that requires this misbehavior.

Do you want to backport this change? It's probably going to cause breakage, which may or may not be desirable.

[griesemer]

I think the question is whether we should change the spec and simply remove the restriction because that's what appears to be implemented anyway.