spec: generics: permit type parameters on aliases

[mdempsky]

The generics proposal says "A type alias may refer to a generic type, but the type alias may not have its own parameters. This restriction exists because it is unclear how to handle a type alias with type parameters that have constraints."

I propose this should be relaxed and type aliases allowed to have their own type parameters. I think there's a clear way to handle type aliases with constrained type parameters: uses of the type alias need to satisfy the constraints, and within the underlying type expression those parameters can be used to instantiate other generic types that they satisfy.

I think it's fine to continue allowing type VectorAlias = Vector as in the proposal, but this should be considered short-hand for type VectorAlias[T any] = Vector[T]. More generally, for generic type B with type parameters [T1 C1, T2 C2, ..., Tn Cn], then type A = B would be the same as type A[T1 C1, T2 C2, ..., Tn Cn] = B[T1, T2, ..., Tn].

In particular, something like this would be an error:

type A[T comparable] int
type B[U any] = A[U]   // ERROR: U does not satisfy comparable
type C B[int]

As justification for this, analogous code in the value domain would give an error:

func F(x int) {}
func G(y interface{}) { F(y) }  // ERROR: cannot use y (type interface{}) as int
func H() { G(42) }

I suspect if TParams is moved from Named to TypeName and type instantiation is similarly changed to start from the TypeName instead of the Type, then this should work okay.

/cc @griesemer @ianlancetaylor @findleyr @bcmills

[findleyr]

If this proposal were accepted, would the following code be valid?

type A[T any] int
type B[U comparable] = A[U]

I.e. would it be possible to define an alias which tightens the constraints of the aliased type?

IMO the example in the value domain is more analogous to defining a new named type, which already behaves as expected:

type A[T comparable] int
type B[U any] A[U] // ERROR: U does not satisfy comparable

Aliasing seems more analogous to function value assignment, for which we don't redeclare parameters:

func F(x int) {}
var G = F

I think you're right about how this could be implemented, but I wonder if it is conceptually coherent. Specifically, I wonder about whether we should think of the declaration as parameterizing the type, or as defining a parameterized type, and whether it still makes sense to call the example with additional restrictions above an alias.

I'll also note that as you point out, our decisions with respect to the go/types API have real consequences for how easy it would be to relax this restriction on aliases in the future, so it is good to talk about this now. Thanks for raising this issue!

[mdempsky]

I.e. would it be possible to define an alias which tightens the constraints of the aliased type?

Yes. U (type parameter with bound comparable) satisfies the constraint any, so that's a valid type declaration in my mind. But similarly, trying to instantiate B[[]int] would be invalid, because []int does not satisfy comparable, even though it satisfies the underlying any.

I would expect that the type checker would see B[[]int], resolve B to the TypeName and check it against the type parameters, and then reject it as invalid, before proceeding to instantiating/substituting its Type with the type argument []int.

Aliasing seems more analogous to function value assignment, for which we don't redeclare parameters:

Note that var G = F is really shorthand there for var G func(int) = F. You're not allowed to write var G func(interface{}) = F, for example, even if you only ever call G with int arguments.

But this is also why I suggest still allowing type A = B as shorthand for explicitly writing out type parameters for the alias declaration.

[griesemer]

There is a reason why we didn't do this in the first place.

I don't have any principal objections to this proposal. If we accept this, I wonder whether we should still permit the type A = B form as it does deviate from the current design which requires that every use of a generic type requires an instantiation.

I'm inclined to proceed in one of two ways:
1) Disallow (not implement) the form type A = B for Go1.17. It's not crucial and we can always add it later.
2) Implement this proposal instead of permitting type A = B.

[bcmills]

I seem to recall @rogpeppe raising a similar point in various conversations.

[bcmills]

@findleyr

Aliasing seems more analogous to function value assignment, for which we don't redeclare parameters:

Note that we do allow function value assignment to strengthen (but not weaken) a type via assignability, which IMO is analogous to strengthening type constraints on a type declaration.

Consider this program:

package main

import "context"

func cancel() {}

type thunk func()

var f = cancel
var g context.CancelFunc = cancel

In that program, var f = cancel is shorthand for var f func() = cancel.

The declaration var g context.CancelFunc = cancel refers to the exact same function value, but with a stronger type (one that is not assignable to thunk).

[jimmyfrasche]

It looks like it could fall out of the definition but, to be explicit, partial application would also be useful:

type Named[T any] = Map[string, T]

[mdempsky]

@griesemer If we proceed with this proposal, I think it could be a nice convenience to keep type A = B as short-hand. But as it's not essential, I'd similarly be fine with just removing it altogether. We can always re-add it in the future if appropriate.

And yes, the deviating from the norm of requiring instantiation is what threw me off. I had written some code that was working under the assumption that if I only started from non-generic declarations, then I would never see a non-instantiated type. But that doesn't hold for the type A = B form. (Fortunately though, it's not hard to special case this one instance either.)

[findleyr]

@bcmills

Note that we do allow function value assignment to strengthen (but not weaken) a type via assignability, which IMO is analogous to strengthening type constraints on a type declaration.

The example from #46477 (comment) made the analogy of function parameters with type parameters (which makes sense). In that analogy, we don't allow changing function parameter types when assigning [example], i.e. we don't support covariant function assignment.

[bcmills]

In that analogy … we don't support covariant function assignment.

Sure, but pretty much the entire point of type parameters is to support variance in types. 😉

[neild]

What is the use case for permitting parameters on type aliases?

[griesemer]

@neild The same reason for which type aliases were introduced in the first place, which is to make refactoring across package boundaries easier (or possible, depending on use case).

I misread this comment. See below.

[griesemer]

Going through my notes I remember now why we didn't go this route in the first place: Note that an alias is just an alternative name for a type, it's not a new type. Introducing a smaller set of type arguments (as suggested above), or providing stronger type constraints seems counter that idea. Such changes arguably define a new type and then one should do that: declare a new defined type, i.e., leave the = away. I note that @findleyr pointed out just that in the 2nd comment on this proposal.
This would mean that the respective methods also have to be redefined (likely as forwarders) but that seems sensible if the type constraints are narrowed or partially instantiated.

In summary, I am not convinced anymore that this is such a good idea. We have explored the generics design space for the greater part of two years and the devil really is in the details. At this point we should not introduce new mechanisms until we have collected some concrete experience.

I suggest we put this on hold for the time being.

[neild]

@griesemer I don't see what the refactoring case is for changing the constraints of a type. As you say, an alias is just an alternative name for a type, but an alternative name with altered constraints is a subtler concept that I struggle to see the use for.

I may be missing something. A concrete example of when you'd use this would be useful.