`erasableSyntaxOnly` should error on unerasable `as`/`satisfies`

[robpalme]

🔎 Search Terms

erasableSyntaxOnly

🕗 Version & Regression Information

• This is the behavior in every version I tried including 6.0.3

⏯ Playground Link

https://www.typescriptlang.org/play/?erasableSyntaxOnly=true&ts=6.0.3#code/MYewdgziA2CmB00QHMAUBGABAak1ghhJmAK4C2ARrAE6YD0mATAJQDcAUJ50A

💻 Code

//@erasableSyntaxOnly:true
console.log(1 + 1 as number / 2);

🙁 Actual behavior

No error - which could lead a naive type-stripping compiler to incorrectly emit:

console.log(1 + 1           / 2);

Though TypeScript itself correctly emits

console.log((1 + 1) / 2);

🙂 Expected behavior

As there is no guaranteed room for (, it should error on this kind of AsExpressions and SatisfiesExpressions

Additional information about the issue

This issue was first discovered by @qnighy and reported as bloomberg/ts-blank-space#62

It was since fixed to emit an error in:

• ts-blank-space v0.9.0
• SWC v1.15.40
• Amaro v1.1.10

[ritschwumm]

wow - i always assumed as to have a higher operator precedence than almost anything except parens.
makes me wonder where this is documented and how i (and obviously a few others) could have missed it.

[snarbles2]

I had the same reaction. I decided that the only reason I'd never run into this weirdness before is because I wouldn't have written that code without parens in the first place. I went looking for documentation that identified the precedence of the as operator and couldn't find it.

Does "erasable syntax only" really imply "blankable"? Or was that just a presumed convenient property?

[acutmore]

Does "erasable syntax only" really imply "blankable"? Or was that just a presumed convenient property?

There is some precedence here. #61244 bans the old <Type>val assertion syntax under erasableSyntaxOnly as that is not generally "blankable" and can require adding parenthesis. For example: () => <Type>{} must become () => ({}) not () => {}.

[RyanCavanaugh]

Does "erasable syntax only" really imply "blankable"? Or was that just a presumed convenient property?

I'm not really sure. We balked at making ESO in the first place since different type-strippers can and do have different capabilities. Blanking-only turned out to be possible in almost all cases but that was not the initial design goal; no one ever discussed this aspect prior to ESO being introduced AFAIK.

[RyanCavanaugh]

Discussed. Key takeaways

• erasableSyntaxOnly should follow the "modern" interpretation of only allowing syntax that can be blanked out while preserving existing character positions (i.e. the fact that as is 2 chars and thus the parens could be inserted is not sufficient to make this OK)
• We shipped what precedence?? See if we can get away with parsing this as 1 + 1 as (number / 2) to get a type expression parsing error, or apply the same logic that ?? has with certain binary operands, e.g. 1 || 2 ?? 3 is an error so maybe 1 + 1 as T can be an error? Worth running top1000 on with Strada and seeing if we can just take a break here in 7.0. It'd have to be an error instead of just a pure precedence change since we don't want to change runtime behavior emit

[ahejlsberg]

The only operators that can meaningfully follow an xxx as T or xxx satisfies T operation in an expression are operators with lower or same precedence as relational operators (which is the classification of as and satisfies). For example, this should be ok:

console.log(1 + 1 as number === 2);

because === has lower precedence than as and therefore the as number can just be erased. However, when an operator with higher precendece follows, it is no longer possible to erase as number without changing the meaning of the expression, so it really doesn't make sense to consider that operator part of the expression.

I'm going to put up a PR that stops parsing when an unexpected operator is encountered. I would be very surprised if that breaks anything in the real world.