Labeled variadic tuples should not require labeling spreads for tuples that are already labeled

[btoo]

Suggestion

🔍 Search Terms

variadic tuples name label element named labeled tuple elements

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Variadic tuples will inherit the labels of the tuples they're spreading

type LabeledTuple = [first: string, second: number]

type VariadicTuplesCanInheritLabels = [...LabeledTuple]
//  ^? type VariadicTuplesCanInheritLabels = [first: string, second: number]

However, once a variadic tuple adds unlabeled elements, the variadic tuple loses the spread tuples' labels and compilation fails

type VariadicTuplesWithoutLabelingALabeledTuple = [...LabeledTuple, third: boolean]
//  ERROR: Tuple members must all have names or all not have names. (5084)

As a workaround, we can label the spread, but this label never gets used. Even worse (and potentially a bug), this label's type is inferred as any

/** `unusedLabel`'s type is incorrectly inferred as `any` */
type VariadicTupleWithUnusedLabel = [...unusedLabel: LabeledTuple, third: boolean]
//  ^? type VariadicTupleWithUnusedLabel = [first: string, second: number, third: boolean]

Following up on #39941 (comment), a better DX might be to not require that Tuple members must all have names if the spread elements are already labeled, which would be consistent with the fact that variadic tuples already inherit the labels of their spreads.

📃 Motivating Example

Playground link

💻 Use Cases

Not having to redundantly label variadic tuple spreads

[RyanCavanaugh]

Discussed and we're OK removing this restriction for all tuple elements. However, #53011 would need to be fixed first, otherwise we might break currently-working declaration emit

[JoshuaKGoldberg]

removing this restriction for all tuple elements

@RyanCavanaugh just to be clear, are you suggesting that the Tuple members must all have names or all not have names restriction is clear to be removed altogether?

[RyanCavanaugh]

Yeah, though we should make the declaration emitter more resilient to this. Sample:

function fn() {
    type M = [a: string, number];

    return f;

    function f(...args: M) { }
}

I think we want the function type in the .d.ts to be something like (a: string, arg_1: number) => void