Closed
Description
Parsing Arrow Functions and Conditionals
- 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.
- How is that flag different from
- 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
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 '?.'