"This condition will always return 'false'" but returns true at runtime

Daniel Rosenwasser (@DanielRosenwasser)

TypeScript Version: 3.1.0-dev.20180818

Code

function sanityCheck(s: string): string {
	return s == 0 ? "I must be going insane" : "I'm fine";
}
console.log(sanityCheck(""));

Expected behavior:

Error message is 100% accurate.

Actual behavior:

src/a.ts:2:9 - error TS2367: This condition will always return 'false' since the types 'string' and 'number' have no overlap.

The == operator in JavaScript converts its arguments -- some developers apparently rely on this behavior (not naming names but I noticed this in real JavaScript code that I pasted into a TypeScript file).
The error message might recommend using an explicit conversion such as Number(s) to get this to compile in TypeScript.

CC Daniel Rosenwasser (@DanielRosenwasser)

Yeah, we discussed == and != making the statement technically incorrect and decided to wait for the first bug report before addressing it.

I think just using the old error message is probably fine.

related #24991

I got this error Operator '==' cannot be applied to types 'string' and 'number'. in Stackblitz.
https://stackblitz.com/edit/typescript-vwakj2

EDIT : Sorry, Typescript current version on Stackblitz shouldn't be 3.1.x

Andy (Andrewkraft) (@Andy-MS)

Andy (Andrewkraft) (@Andy-MS) Sorry my snippet wasn't saved! Now it has been updated :)

I get the same error message for the following code:

I have a similar scenario. Here is the minimal reproduction:

enum types {
  type1 = 'type1',
  type2 = 'type2'
}

class A {
  private h: types = types.type1;
  
  private a() {
    this.h = types.type2;

    this.b();
    // Actual error here: the method b changes h to types.type1. But typescript thinks this.h would always be types.type2.
    if (this.h === types.type1) { // This condition will always return 'false' since the types 'types.type2' and 'types.type1' have no overlap.

      console.log('hello')
    }
  }

  private b() {
    this.h = types.type1;
  }
}

See it live here: https://stackblitz.com/edit/typescript-qvs8ov

Is this not getting fixed?

I started to use @typescript-eslint/strict-boolean-expressions after I found a silly mistake in my code that could have costed me a lot of money, as I did a numberOrUndefinedVar ? X : Y, and 0 was not intentionally falling into Y, and it was making hundreds of DB calls.

This rule is very good, but, doesn't work very good with TS due to a current fact: If you want to check a falsy value (e.g. empty string and undefined), with == false, TS will throw This condition will always return 'false' since the types 'string | undefined' and 'boolean' have no overlap.ts(2367).

I have made, before this == false idea, a question in Stackoverflow about it, how to check for falsy value using this rule. While the two current answers are valid, they really aren't good to use outside your own code, where you know why you are using it and won't need to comment why you did those strange workarounds.

So, == false should be TS friendly, as it works as expected in JS.

Current TS version: 4.1.2

are we getting fix?

Can someone point more specifically to where this error-check happens, to facilitate a PR that disables the check for == and != cases? I'm not able to find it, even in code search.
To see that this bug has been known for years with an intentional decision to just not fix it until there were a sufficiently large number of errors - and then it not being fixed after that threshold was exceeded - really communicates that TypeScript isn't ready for prime-time use or production code yet.

It really annoys me that this has been a bug for years and looks like the devs here have no interest in resolving it. Not only is the error message misleading and wrong, TypeScript is failing to be a superset of JavaScript as it's not allowing me to do perfectly valid JavaScript.

Frankly whether anyone considers it to be bad practice to allow an implicit conversion or not is irrelevant. We who are developing our own code should be allowed to make that choice for ourselves. I as the developer should be able to choose what parts of the language I use to the fullest.

TypeScript is failing to be a superset of JavaScript as it's not allowing me to do perfectly valid JavaScript.

It has never been the case that no JS you could possibly write would issue zero errors in TypeScript, nor would this make any sense. See https://stackoverflow.com/questions/41750390/what-does-all-legal-javascript-is-legal-typescript-mean

Navigation Menu

Repository navigation

"This condition will always return 'false'" but returns true at runtime #26592

21 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

"This condition will always return 'false'" but returns true at runtime #26592

Description

Activity

DanielRosenwasser commented on Aug 22, 2018

DanielRosenwasser commented on Aug 22, 2018

Kingwl commented on Aug 22, 2018

HZooly commented on Aug 27, 2018

HZooly commented on Aug 28, 2018

JohnPool commented on Oct 22, 2018

21 remaining items

vigneshTheDev commented on Jan 1, 2020

shalomhalbert commented on Jun 23, 2020

ftzi commented on Nov 21, 2020

TomasSestak commented on Aug 17, 2021

wbt commented on Mar 11, 2022

BlackAsLight commented on Aug 22, 2022

RyanCavanaugh commented on Aug 25, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions