Strange boolean-discriminant narrowing with strictNullChecks off

TypeScript Version: nightly (2.1.0-dev.20160826)

Code

type Result = { success: true }
            | { success: false, error: string }

function handleError(res: Result) {
    if (res.success === true) {
        return;
    }

    res.error; // OK
}

function handleError2(res: Result) {
    if (res.success !== false) {
        return;
    }

    res.error; // OK
}

function handleError3(res: Result) {
    if (res.success) {
        return;
    }

    res.error; // Property 'error' does not exist on type 'Result'
               // but should be OK
}

Expected behavior:
All three cases should behave the same.

This is correct. We don't know that res.success isn't undefined or null, which would mean it's possibly not false and therefore not { success: false, error: string }

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) While you are technically right (and I was thinking the same), when strictNullChecks is off null and undefined are not modelled at all and such differences don't surface in other situations. For example handleError has exactly the same semantics but compiles just fine. I think the behaviour should be consistent or at least the error message should be more descriptive.

what is the expected behavior?

Daniel Rosenwasser (@DanielRosenwasser)

Daniel Rosenwasser (@DanielRosenwasser) I have the same question

This is correct. We don't know that res.success isn't undefined or null, which would mean it's possibly not false and therefore not { success: false, error: string }

I'm wondering why the if (res.success === true) { example above should compile then, because couldn't success still be undefined or null in the else block?

Hey, I just wanted to point out that this issue now has additional relevance in TypeScript 3.6 due to the addition of the Generator type and the new IteratorResult type. I was writing some code with generators, expecting I could use while(!result.done) to loop over the case where the generator was not done, but found in fact I had to use while(result.done === false). Might be a reason to revisit this?

I have experienced similar behaviour, and the following code helped me to work around this limitation:

(Assuming we have foo with the discriminating boolean-property "discBool" and the optional property "optionalProperty" which is only present in one of the two sub-types of foo's super-type. In other words: If discBool is false, optionalProperty is present, if discBool is true, optionalProperty is not present in foo)

switch (foo.discBool) {
  case false:
    doSomething(foo.optionalProperty);
}

while this code didn't work:

if (!foo.discBool) {
  doSomething(foo.optionalProperty); // Error here
}

chore(tsconfig): enable strictNullChecks and noImplicitAny

This now works as expected

Navigation Menu

Repository navigation

Strange boolean-discriminant narrowing with strictNullChecks off #10564

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Strange boolean-discriminant narrowing with strictNullChecks off #10564

Description

Activity

RyanCavanaugh commented on Aug 26, 2016

gcnew commented on Aug 26, 2016

Kingwl commented on Sep 13, 2018

RyanCavanaugh commented on Sep 13, 2018

kevinder commented on Sep 13, 2018

haltman-at commented on Sep 3, 2019

Tanja-4732 commented on Jul 25, 2020

RyanCavanaugh commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions