We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#28259 #38234
Tuple of [number, number] is not as useful without ability to communicate that the first element is the start, second is the length.
[number, number]
start
length
People did some funky stuff - "write a parameter list, you can get named tuples!"
Have an implementation of this.
...
?
Signature help seems to work.
The names have absolutely no significance.
What about with union of tuples?
Sample
type Segment = [start: number, length: number];
0
Should tuples enforce anything about the names they destructure to?
Question is whether this has type system implications. Stance seems to be that this is purely for readability and tooling.
The inconsistency in placement of ... and ? seems bad, but we gracefully parse and give errors.
How do we deal with multiple overloads with one signature with unions of these named tuple rest elements?
Should we "traffic" the doc comments as well?
Do these names "survive" mapped types?
Conclusion
1
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Tuple Types with Named Members
#28259
#38234
Tuple of
[number, number]
is not as useful without ability to communicate that the first element is thestart
, second is thelength
.People did some funky stuff - "write a parameter list, you can get named tuples!"
Have an implementation of this.
...
and?
goes, but we have some good errors here.Signature help seems to work.
The names have absolutely no significance.
What about with union of tuples?
Sample
0
th element.Should tuples enforce anything about the names they destructure to?
Question is whether this has type system implications. Stance seems to be that this is purely for readability and tooling.
The inconsistency in placement of
...
and?
seems bad, but we gracefully parse and give errors.How do we deal with multiple overloads with one signature with unions of these named tuple rest elements?
Should we "traffic" the doc comments as well?
Do these names "survive" mapped types?
Conclusion
0
,1
, on their own as well.The text was updated successfully, but these errors were encountered: