You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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 '?.'
The text was updated successfully, but these errors were encountered:
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.c
can 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
The text was updated successfully, but these errors were encountered: