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'.
-
@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 '?.'
Parsing Arrow Functions and Conditionals
#49531
:, and yield to the outer conditional parsing.allowAmbiguity?Parsing Instantiation Expressions in Property Accesses and Optional Chaining
#49464
Idea from last discussion was to parse out
a?.b<T>and then say "oops! I don't think.ccan continue the property access."Lots of tests written expecting this to continue parsing.
Also, the new parsing tests are not always great.
@nicolo-ribaudo had two different cases
Conclusion