RFC: Type alias type packs

[vegorov-rbx]

Rendered link

[alexmccord]

I think that I would prefer to have this as X<()>.

[vegorov-rbx]

Should we open a straw poll?

[zeux]

I feel like there's only two consistent syntaxes:

• When specifying type pack arguments, you must specify a type pack explicitly. This means that we don't automatically restructure input sequences, so X<number, string> fails when X accepts one type pack parameter
• When specifying type pack arguments, and type pack isn't explicitly specified, we take a sequence of types until the last type, or possibly until the next type pack (?), and convert that to a type pack.

In the latter case it feels like X<> should indeed work and produce an empty type pack parameter.

[vegorov-rbx]

I had the first option as an alternative in a draft, but I didn't even want to consider that:

One option that we have is to remove implicit pack assignment from a set of types
and a trailing tail and always require new explicit type pack syntax:

type X<T...> = --

type A<S...> = X<S...>        -- invalid
type B = X                    -- invalid
type C = X<number>            -- invalid
type D = X<number, string>    -- invalid
type E = X<...number>         -- invalid

type A<S...> = X<(S...)>      -- T... = (S...)
type B = X<()>                -- T... = ()
type C = X<(number)>          -- T... = (number)
type D = X<(number, string)>  -- T... = (number, string)
type E = X<(...number)>       -- T... = (...number)

But this doesn't feel natural and for variadic function argument lists, the syntax for
the argument tail is not special.

[vegorov-rbx]

Types A and E might still work without (), but like I've said it was a draft that I didn't explore.

[tiffany352]

I find explicitly representing packs this way to be a surprising direction, but that might just be my familiarity with C++ templates talking. It'd be nice if the rationale for doing it this way was explained a bit more, instead of only how it works mechanically.

It'd still be possible to implement splitting in the future through a magic utility type, right? Something like Select<T..., number>.

[vegorov-rbx]

I think it's correct to use 'direction' when talking about something new.
This RFC doesn't select a direction in how type packs works here, this is an existing limitation of the current type system (eager type alias definitions).
If this element of the type system changes (in a different RFC), splitting off type pack elements might become available.

[vegorov-rbx]

It would also be great to see useful examples of type pack element extraction in context of Luau programs.

[matthargett]

Would this allow me to do the following? As we start looking at strongly-typing dynamic data fetch/mutation, this kind of composability will be more and more important.

type void = ()
type tuple<T...> = (T...)
type F<ReturnT> = () -> ReturnT
type voidF = F<()>
type voidF2 = F<void>
type tupleF = F<tuple<string, () -> tuple<number, number>>>
type Obj = { f: voidF, f2: voidF2, useEffect: tupleF }
local obj: Obj = {
  f = function() end,
  f2 = function() end,
  useEffect =  function()
    return "xyz", function() return 90210, 31337 end
  end
}

[zeux]

No, the code above tries to declare a type pack alias, and this RFC is about generic type pack arguments to type aliases. Type aliases continue to name types, not type packs.

[vegorov-rbx]

Would this allow me to do the following? As we start looking at strongly-typing dynamic data fetch/mutation, this kind of composability will be more and more important.

This example doesn't look very strong, you would be able to write:

type F<ReturnT...> = () -> ReturnT...
type voidF = F<()>
type voidF2 = F<()>
type tupleF = F<(string, () -> (number, number))>
-- code below is the same

If there are better examples, that's something outside of this RFC's scope as @zeux mentioned.

[vegorov-rbx]

Updated to remove combining extra types together with the next type pack into a single type pack argument, only types are combined.
Also added an alternative about using only explicit type packs.

[zeux]

Thanks a lot for thinking this through; I've reread the RFC again and I think this proposal results in something that is easy to think about and use.