-
Notifications
You must be signed in to change notification settings - Fork 13k
Description
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
π» Use Cases
Not having to redundantly label variadic tuple spreads