spec: unclear whether it is ok to have a type parameter as the RHS in an alias type declaration

[griesemer]

Per the spec:

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

This matches the respective restriction we have for type definitions.
That said, we have quite a few (type checker) tests that declare local aliases for function type parameters.

This restriction should probably only apply to package-level alias declaration. But even that is not clear.
Needs to be investigated.

See also #75884.

cc: @findleyr @adonovan @mrkfrmn

[gabyhelp]

Related Issues

• spec: generics: permit type parameters on aliases #46477 (closed)
• go/types, types2: type checker accepts invalid program #75884
• go/types: TypeName.IsAlias reports true for type parameters #49213 (closed)
• go/types, cmd/compile/internal/types2: disallow type parameters as RHS of type declarations #45639 (closed)
• spec: type alias identity unclear #23790 (closed)
• type alias with type that have type parameters doesn't work in go1.18rc #51516 (closed)
• go/types: implement type-checking of alias declarations #17592 (closed)
• cmd/compile: handle alias types in recursive types more consistently #50729 (closed)
• cmd/compile: allow parameterized type aliases to omit redundant type parameters #68617
• spec: should accept method recv base type that is alias to a pointer type #27995 (closed)

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

[griesemer]

cc: @ianlancetaylor for visibility.

[ianlancetaylor]

I see no difficulty with a function-local type alias to a type parameter of the enclosing function (though I don't know why anybody would want to write that). The confusing case would seem to be aliasing a type to a parameter of itself.

[adonovan]

I don't see anything wrong in principle without allowing type A[T any] = T, and I can imagine (again, in principle) useful applications: generic aliases could be used as type constructors and deconstructors:

type Slice[T any] = []T
type Unslice[T ~[]E, E any] = E

type I = int
fmt.Printf("%T %T %T",
		reflect.TypeFor[I](),
		reflect.TypeFor[Slice[I]](),
		reflect.TypeFor[Unslice[Slice[I]]]()) // <-- this isn't allowed but it could be.

This doesn't quite work because you have to specify all the type arguments to Unslice[·, ·], but that restriction could be lifted.

[findleyr]

I agree with Alan, that we should probably allow type X[T any] = T anywhere, for consistency, though this requires more investigation.

I'll just note that the when T is a type parameter, the difference between type X T and type X = T is really subtle, considering we allow both forms whenever T is not a type parameter. That we can't allow type X T is because we decided that the underlying type of a type parameter is its constraint interface, and so the declaration loses all information about T, and this would be very confusing and would indirectly allow access to generalized interfaces outside of constraint position!

[mrkfrmn]

I also don't see much of a problem with function-local aliasing of type parameters, but agree that it's not that useful anyway.

That we can't allow type X T is because we decided that the underlying type of a type parameter is its constraint interface

I was under the impression that the underlying being a constraint interface was necessary specifically to permit the RHS being a type parameter, or at least that's how I interpreted this snippet:

// We don't need this restriction anymore if we make the underlying type of a type
// parameter its constraint interface: if the RHS is a lone type parameter, we will
// use its underlying type (like we do for any RHS in a type declaration), and its
// underlying type is an interface and the type declaration is well defined.
if isTypeParam(rhs) {
  ...
}

Perhaps this comment needs an update?

so the declaration loses all information about T

I assume this is because we only encode the underlying type in export data? Or is there another reason this is true?

[findleyr]

Perhaps this comment needs an update?

I believe that comment is misleading, per my previous comment on this issue: the only possible definition of type X T would be a type X with underlying equal to the constraint interface of T, but that's extremely confusing to the point of being unusable, and would allow use of generalized interfaces outside of constraint position. We cannot allow type X T, nor can we allow type X[T any] T.

Put differently: underlying forwarding can only work if we actually know what the underlying is, and we don't know that for type parameters. That we define it to be the constraint interface is just a convention to make a type parameter look like an ordinary type in the go/types API.

[findleyr]

I assume this is because we only encode the underlying type in export data? Or is there another reason this is true?

No, it loses this information in the go/types API, and in the spec, due to underlying forwarding.
We record fromRHS during type checking, but that's just an implementation detail.

[griesemer]

What @findleyr said. That comment is confusing and needs to be updated (I was starring at it last night). I will take care of it.