Skip to content

Eliminate self-assignment from emitted code (to allow explicit type-casts) #21323

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

Closed
mindplay-dk opened this issue Jan 21, 2018 · 2 comments
Closed
Labels
Duplicate An existing issue was already created

Comments

@mindplay-dk
Copy link

I have a case similar to this:

if (a instance of A) {
    do_something_with(a, b)
    return
}

b = b as B // "explicit type-cast"

That is, the type (or exact type) of b isn't known when entering this block of code - but eliminating one case where the type of a becomes known, because the type of a tells me something about the type of b, I can make a safe assumption about the type of b in the remainer of the block.

Is there another way to type-cast b for the remainder of the block other than the redundant assignment b = b, which gets emitted?

If not, I'd like to suggest the compiler simply eliminate this obviously redundant self-assignment.

Alternatively, perhaps allowing some kind of declare statement might be more appropriate?

Here's the concrete example, in which typeof vNode has been narrowed down to "object", which implies target must be TargetElement.

It's not the first time I've run into this problem, and as far as I can figure, there isn't a type constraint or a trick with generics or something that will fix this - if there is, I'd love to hear about it of course, but every time I've run into this issue, self-assignment has been the only solution I could dig up.

@RyanCavanaugh
Copy link
Member

Previously discussed at #10421 / #9946 / #6474 / #13426

@mhegazy mhegazy added the Duplicate An existing issue was already created label Jan 24, 2018
@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@microsoft microsoft locked and limited conversation to collaborators Jul 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

4 participants