Skip to content

And expression inferrs wrong type. #26468

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
dbaeumer opened this issue Aug 15, 2018 · 6 comments
Closed

And expression inferrs wrong type. #26468

dbaeumer opened this issue Aug 15, 2018 · 6 comments
Labels
Breaking Change Would introduce errors in existing code Bug A bug in TypeScript Won't Fix The severity and priority of this issue do not warrant the time or complexity needed to fix it

Comments

@dbaeumer
Copy link
Member

dbaeumer commented Aug 15, 2018

TypeScript Version: 3.1.0-dev.201xxxxx

Search Terms:

Code

let b: boolean;
let s: string;

let x = b && s;

Expected behavior:

The inferred type of x is boolean | string;

Actual behavior:

The inferred type of x is string;

Playground Link:

https://www.typescriptlang.org/play/#src=let%20b%3A%20boolean%3B%0D%0Alet%20s%3A%20string%3B%0D%0A%0D%0Alet%20x%20%3D%20b%20%26%26%20s%3B

Related Issues:

@AlCalzone
Copy link
Contributor

Since the type of x seems to take the value of b into account, should the type even be string?

let b: boolean;
let s: string;

let x1 = b && s; // string, (which should it be? x1 is undefined)

b = true;
let x2 = b && s; // string

b = false;
let x3 = b && s; // boolean

@markusjohnsson
Copy link
Contributor

With strictNullChecks, you will get string | boolean.

@RyanCavanaugh RyanCavanaugh added the Bug A bug in TypeScript label Aug 15, 2018
@RyanCavanaugh RyanCavanaugh added this to the TypeScript 3.1 milestone Aug 15, 2018
@RyanCavanaugh RyanCavanaugh added the Breaking Change Would introduce errors in existing code label Aug 15, 2018
@RyanCavanaugh
Copy link
Member

@ahejlsberg in non-SNC we should really be keeping the left operand type in the result when it's a primitive

@ahejlsberg
Copy link
Member

We've discussed fixing this before, but decided against it because of the breaking change. Do we feel differently about this now?

In general, if you care about precise types you really should be using --strictNullChecks (where we type this correctly).

@RyanCavanaugh
Copy link
Member

I don't recall that discussion. We could check RWC for impact - seems like we'd reveal a ton of subtle bugs

@RyanCavanaugh RyanCavanaugh modified the milestones: TypeScript 3.1, Future Aug 17, 2018
@RyanCavanaugh RyanCavanaugh removed this from the Future milestone Aug 20, 2018
@RyanCavanaugh RyanCavanaugh added the Won't Fix The severity and priority of this issue do not warrant the time or complexity needed to fix it label Aug 20, 2018
@RyanCavanaugh
Copy link
Member

RWC results were nothing but false positives. Doesn't seem worth breaking at this point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change Would introduce errors in existing code Bug A bug in TypeScript Won't Fix The severity and priority of this issue do not warrant the time or complexity needed to fix it
Projects
None yet
Development

No branches or pull requests

5 participants