Skip to content
New issue

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

Design Meeting Notes, 5/1/2020 #38292

Closed
DanielRosenwasser opened this issue May 1, 2020 · 0 comments
Closed

Design Meeting Notes, 5/1/2020 #38292

DanielRosenwasser opened this issue May 1, 2020 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented May 1, 2020

Tuple Types with Named Members

#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.

  • 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.
  • 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 0th element.
    • We also don't provide good tuple completions - we should.
  • 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.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label May 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants