Closed
Description
Search Terms
tuple type elements members labels names naming
Suggestion
Currently tuple types are defined like so:
// length, count
type Segment = [number, number];
I often find myself having to add labels to the elements of the tuple as a comment b/c the types themselves (number, string) don't adequately describe what the elements represent.
It would be nice if we could add labels to tuple elements using syntax similar to function parameters like so:
type Segment = [length: number, count: number];
Use Cases
Currently we use comments to describe tuples, but adding this information directly to the AST can provide additional information for tooling.
Examples
This new syntax would also be useful in return types:
function createSegment(/* ... */): [length: number, count: number] {
/* ... */
}
Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript / JavaScript codeThis wouldn't change the runtime behavior of existing JavaScript codeThis could be implemented without emitting different JS based on the types of the expressionsThis isn't a runtime feature (e.g. new expression-level syntax)
Activity
[-]Adding labels to tuple elements[/-][+]Add labels to tuple elements[/+][-]Add labels to tuple elements[/-][+]Feature Request: Add labels to tuple elements[/+]DanielRosenwasser commentedon Oct 31, 2018
This could be useful for spreading in argument lists, but why wouldn't you use an object literal instead?
brainkim commentedon Oct 31, 2018
Actually, I don't see this feature being very useful in argument lists, b/c the variables you name in the destructuring expression implicitly label the elements of the tuple:
As for why one would use tuples in a return type vs. objects, or really, why one would use tuples over objects generally; sometimes, it's easier to have data structures with positional values rather than named values, such as when one has to write a bunch of these values (for tests, etc). Consider:
vs.
Using tuples gets rid of a lot of repetition/noise.
Additionally, in recent news, the React team is proposing a new API called hooks which is based on returning/destructuring tuples.
Using named tuples as a return value:
seems much more descriptive than using unnamed tuples:
DanielRosenwasser commentedon Nov 16, 2018
I mean more in terms of when you indirectly spread a tuple type into a parameter list. It's pretty niche though.
sindresorhus commentedon Jan 9, 2019
Named tuple elements would improve code readability. I currently have
quality?: [number, number];
, which would be much more readable asquality?: [min: number, max: number];
.streamich commentedon Nov 28, 2019
I've run into this when I have to define function parameters as a tuple, now I do
Then when I use
MyFunction
function autosuggestion shows me that "arg 0" is of typenumber
. But it would be great if instead of "arg 0" there would be an actual name.For example named tuple could solve this:
kourge commentedon Dec 5, 2019
It's worth mentioning that this feature already exists in TypeScript today, but it does not have syntax of its own:
Written this way, the arguments of
MyFunction
retain their names.martinheidegger commentedon Mar 25, 2020
Adding to this: I think it might be nice to have human readable label fallbacks, i.e.:
ikokostya commentedon Apr 29, 2020
Proposed feature doesn't improve readability in call sites. For example
This is obvious if use interface instead of tuple:
Rule is very straightforward: if meaning of elements is obvious, then use tuple. Otherwise, use interface. Similar to positional and named arguments. I'm afraid that with new syntax people will start to use tuple in unsuitable places.
The provided example is synthetic. How proposed feature should improve readability in such case? Also, you can always write helper function to reduce repetition.
Moreover, the proposed feature doesn't protect from errors at compile time when order of elements in tuple is changed:
13 remaining items
remcohuijser commentedon Aug 10, 2020
One other case I just thought of where using the labels in code might be useful is refactoring. Let's take this function:
Now change the return type to something else:
I guess in this case all hell breaks loose as you will get no compile errors and have to go through all code by hand to adjust it.
mohsen1 commentedon Aug 10, 2020
@vitaly-t @remcohuijser you seems to forget TypeScript is a type system for JavaScript. The code examples you provided are not valid JavaScript code to begin with. That's why readers are confused with your comments. I understand that in other languages such as Swift you can access tuple members via labels and indices. But in TypeScript a tuple is simply an array. A tuple type is describing an array so you can't use labels (type information) to access tuple values (runtime values).
vitaly-t commentedon Aug 10, 2020
@mohsen1 But what does stop TypeScript from simply replacing those names with indexes during transpilation? That was the idea I tried to convey from start. This would not affect JavaScript in any way, but make TypeScript code way more readable.
@remcohuijser Cheers, I rephrased my initial post for more leniency :)
remcohuijser commentedon Aug 11, 2020
@mohsen1 you are quite right: I forgot about this. I come from a Haxe background by the way. I have read other people state that TypeScript is just a typing system. This would mean that TS just reads files, checks them, and then you are done.
In practice, there are cases where TS is doing a lot more. One obvious example I can think of is JSX (which is not valid JS) that gets compiled to the createElement function call. Others are compilation to ES5, decorators, or even the compiler API.
To me, this shows that yes, the basis of TS is a typing system, but there are optional compiler behaviors that one can enable.
Getting back to this topic: I can imaging that you can "enable" the rewrite behavior so that labels of tuple elements can be used in code. What do you think?
@vitaly-t I am always a bit hesitant to give feedback on the internet 🤣 Thank you for responding is such a professional way!
weswigham commentedon Aug 11, 2020
Right, so, officially, we won't ever do the whole "dotted access for labels get transpiled to numbers" thing, because that's type directed (therefore error prone in the presence of inaccurate types or
any
), and our philosophy is not to add type directed emit features. (Such features also don't work in Babel, which would be a big problem!) That's the final word on that, and we've said as much in the original issue requesting labels.A lot of why we added labels is for:
remcohuijser commentedon Aug 11, 2020
@weswigham I think I have to do some more reading on the design goals of TS and type-directed emits. Thank you for pointing this out.
mohsen1 commentedon Aug 11, 2020
I don't think accessing members with a label via dots will ever work if you want to. Take this as an example:
camsjams commentedon Sep 2, 2020
Thank you for this new feature! I think it's extremely useful when peeking at Tuples and trying to surmise exactly which item is which!
🎉
techieshark commentedon Nov 8, 2020
In case anyone lands here and wants the TL;DR version:
https://devblogs.microsoft.com/typescript/announcing-typescript-4-0/#labeled-tuple-elements
targetValue
should be recursed sindresorhus/map-obj#29smashah commentedon May 17, 2021
Is there any way to reference the labels of the tuple as a type itself?
e.g:
RyanCavanaugh commentedon May 21, 2021
@smashah no; these are purely for display purposes (similar to parameter names in function types)
Neme12 commentedon Mar 6, 2024
This makes sense to me, but at least I think the compiler could provide better error messages when someone tries accessing tuple elements by dotted access, explaining that they have to use an index (or deconstruct the tuple).