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, 6/17/2022 #49595

Closed
DanielRosenwasser opened this issue Jun 17, 2022 · 0 comments
Closed

Design Meeting Notes, 6/17/2022 #49595

DanielRosenwasser opened this issue Jun 17, 2022 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Parsing Arrow Functions and Conditionals

#49531

  • Had come up with a bunch of different PRs.
    • Most-desirable one was "if it's valid in JS, it must be valid in TS - but otherwise if it works today in TS, it should continue to work in TS".
    • That's what we're pursuing.
    • How? If you're in a conditional, pass a flag as we parse an arrow function. That flag signals whether we should stop parsing when we hit a :, and yield to the outer conditional parsing.
      • How is that flag different from allowAmbiguity?
        • Ehh. Different use-cases.
  • Does this change how TypeScript emits? Stuff might still parse, but are the semantics different?
    • Not blocking for the beta, but would be good to validate.
    • Also, run on Definitely Typed to see how it works.

Parsing Instantiation Expressions in Property Accesses and Optional Chaining

#49464

a.b<T>.c

// and

a?.b<T>.c
  • Idea from last discussion was to parse out a?.b<T> and then say "oops! I don't think .c can continue the property access."

  • Lots of tests written expecting this to continue parsing.

  • Also, the new parsing tests are not always great.

    // Uh oh
      foo?.bar<Type>.baz
    //~~~~~~~~
    // Object is possibly 'undefined'.
    • We can improve this.
  • @nicolo-ribaudo had two different cases

    // (first)
    a?.<b>();
    
    // (second)
    a<b>?.();
    • Both are sort of reasonable but second is bannable for consistency.
    • PR doesn't disallow it though.
  • Conclusion

    a?.b<T>.c
    //     ^
    // Illegal here.
    // An instantiation expression cannot be followed by a '.'
    
    a<T>?.b.c
    //  ^^ Illegal here.
    // An instantiation expression cannot be followed by a '?.'
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jun 17, 2022
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