RFC: Default type alias type parameters

[vegorov-rbx]

No description provided.

[alexmccord]

Interaction with default type arguments and variadic type parameters seems to be missing in this RFC.

Are we going to support that, or leave it out?
Should the syntax look like type F<R... = (string, number)> = () -> R...?

[vegorov-rbx]

Interaction with default type arguments and variadic type parameters seems to be missing in this RFC.

It's not left out, it's explicitly prohibited: Default type arguments are not allowed for type pack parameters.

[alexmccord]

Ah, got it. What's the rationale for leaving it out to start with? Keeping the scope smaller on a as-needed basis?

[vegorov-rbx]

The reasoning behind the decision is that while we parse type<R...> right now, it's impossible to reference R on the right-hand-side.

I had this text in an unpublished draft:

Default type arguments are allowed for generic type pack parameters:

type A<T, U... = ...string> -- ok, variadic type pack
type B<T, U... = (number, number)> -- ok, type pack of two types
type B<T..., U... = T> -- ok
type A<T, U... = string> -- ok, variadic type pack of one type

[vegorov-rbx]

Since the only reason is a missing related feature, maybe I should bring default type pack values back and we'll fix that issue during implementation of this RFC (if it's accepted).

[matthargett]

Great to see progress on this!

[vegorov-rbx]

@alexmccord I've updated the RFC to include default values for type packs.

[andyfriesen]

-- ambiguity, Type could mean Type<number, string> or Type<A, B>
type Type<A = number, B = string> = { x: number, b: Type? }

I don't like the idea that this could ever mean Type<A, B>. It might be mildly convenient shorthand, but I think it's much more valuable to be able to see Type? and know that it always means Type<number, string> no matter where in the source code you happen to see it.