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

Ban old-style type assertions under erasableSyntaxOnly #61244

Conversation

jakebailey
Copy link
Member

@jakebailey jakebailey commented Feb 21, 2025

Code like ()=><any>{} is not erasable, since ()=> {} is a different tree, and there's nowhere to add parens to the body without shifting its contents backwards one character. If there were extra spaces after the {}, maybe it'd work, but that's atypical.

This PR bans this specific case, though, I personally feel like banning the old-style assertions would be a good idea too.

Updated the PR to just ban them. There are too may edge cases IMO.

@ajafff
Copy link
Contributor

ajafff commented Feb 24, 2025

you probably want to ban it in more places:

// return and yield ASI
function *foo() {
    yield <any>
        1;
    return <any>
        1;
}

// at the start of an ExpressionStatement if followed by an object literal; though I'm not sure why one would use it there
<unknown>{foo() {}}.foo();

// at the start of an ExpressionStatement if followed by function keyword
<unknown>function() {}();
<unknown>function() {};

// at the start of an ExpressionStatement if followed by an anonymous class expression
// note that this exact syntax currently emits invalid JS (no parenthesis added like for function above)
<unknown>class {}

there's probably more parsing ambiguity I cannot remember right now.

@jakebailey
Copy link
Member Author

Yeah, so that furthers my feeling that this syntax should be wholly banned in this mode. I tried to carve something out, but it sure doesn't seem like that's tractable if we want to ban something here.

@acutmore
Copy link
Contributor

acutmore commented Feb 26, 2025

When I was first creating ts-blank-space I tried to write the logic that only errors on the 'actual' bad cases but ended up coming to the conclusion that this may be more confusing to try and explain. This is why I ended up always erroring on the old style of type assertions and recommended code replaces them with as style assertions. The extra win of migrating to as is that code can more easily be moved to a .tsx file without getting sometimes cryptic errors.

@jakebailey jakebailey changed the title Ban old-style type assertions as arrow function bodies under erasableSyntaxOnly Ban old-style type assertions under erasableSyntaxOnly Feb 26, 2025
@jakebailey
Copy link
Member Author

Updated the PR to just straight up ban the syntax.

@jakebailey jakebailey merged commit 1539234 into microsoft:main Feb 28, 2025
32 checks passed
@jakebailey
Copy link
Member Author

@typescript-bot cherry-pick this to release-5.8

@typescript-bot
Copy link
Collaborator

typescript-bot commented Feb 28, 2025

Starting jobs; this comment will be updated as builds start and complete.

Command Status Results
cherry-pick this to release-5.8 ✅ Started ✅ Results

@typescript-bot
Copy link
Collaborator

Hey, @jakebailey! I've created #61320 for you.

@jakebailey jakebailey deleted the erasable-syntax-only-old-school-type-assertions branch February 28, 2025 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

5 participants