Description
Tuple Types with Named Members
-
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.
- Some awkward requirements about where
...
and?
goes, but we have some good errors here.
- Some awkward requirements about where
-
Signature help seems to work.
-
The names have absolutely no significance.
- (we should probably have a good error message there)
-
What about with union of tuples?
- Could make this appear as a series of overloads in the language service.
-
Sample
type Segment = [start: number, length: number];
- Completions on tuple label should give you the
0
th element. - We also don't provide good tuple completions - we should.
- Completions on tuple label should give you the
-
Should tuples enforce anything about the names they destructure to?
- Some users had expectations.
-
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.- Similar to optional chaining and non-null assertion - we changed parsing to have an "inconsistent" parse strategy, but works "intuitively".
- We have a lot of upvotes, just ask users.
-
How do we deal with multiple overloads with one signature with unions of these named tuple rest elements?
- See if they all have the same return type?
-
Should we "traffic" the doc comments as well?
- Yes
- Should we allow JSDoc on eleemnts?
- I guess?
- But are these cached internally? Does that mean people get irrelevant docs?
-
Do these names "survive" mapped types?
- Yes
-
Conclusion
- Ask users about modifiers
- Completions
- lists should have labeled tuple elements
- Completions should provide
0
,1
, on their own as well. - Ensure this works with the VS side.
- Signature Help
- Create signatures across rest element union types.