`x && x` should not be `NonNullable`

[zeng-y-l]

🔎 Search Terms

logical and, generic, NonNullable

🕗 Version & Regression Information

There has been this problem since 4.8.4 (I tried it on the playground)

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAZjAvDAPAFQDQD4AUAPALhjQEoksY8YAyaymAegdTV0OLMQoDlxuBXADaCAhgCNBAU3RYAUEA

💻 Code

const f = <T,>(x: T) => x && x // <T>(x: T) => NonNullable<T>

🙁 Actual behavior

Since f returns NonNullable<T>, we can make every value NonNullable, and never can be created by calling f(null).

🙂 Expected behavior

f should return T.

Additional information about the issue

No response

[jcalz]

Not a TS team member, feel free to ignore everything I say here

Looks like the getDefinitelyFalsyPartOfType() function in checker.ts doesn't handle generic type parameters at all, and just assumes that never is the definitely falsy part instead of something like Extract<0 | 0n | "" | null | undefined | false | void, Type>. This affects more than just x && x, but x && anything where x is generic.

You could sort of kind of do this in userland to get behavior similar to what one might expect:

type _AndAnd<L, R, F> = (F extends L ? F : never) | (L extends F ? never : R)
type AndAnd<L, R> = _AndAnd<L, R, 0 | 0n | "" | null | undefined | false | void>
function andAnd<const L, const R>(l: L, r: R) {
    return l && r as AndAnd<L, R>
}

const f = <T,>(x: T) => andAnd(x, x)
//    ^? const f: <T>(x: T) => AndAnd<T, T>

const nul = f(null);
//    ^? const nul: null

Playground

but that doesn't do cfa on correlated operands and I might have made a mistake in there. Anyway I'd guess this might just be a design limitation or a won't fix since doing the extra work to deal with generics might not be warranted?

[976520]

@zeng-y-l

I wrote some test code related to this issue here 976520@0414038

Could you take a look and let me know if it matches what you had in mind?
If it looks good, I’d like to use it as a basis for a fix and open a PR

[zeng-y-l]

@976520 Thanks, that's good!

I think the type annotations of f1 and f2 at line 35-36 can be removed to make the return type of the arrow functions clearer.

My actual code looks like this. Can it work?

var f3 = <T extends undefined>(x: (() => void) | T) => x && (() => x());
var f4 = <T extends undefined, U extends undefined>(x: (() => void) | T, y: (() => void) | U) => x && y && (() => { x(); y() });

[976520]

@zeng-y-l

After applying my changes, your code is inferred with the following types. is this what you intended?

var f3: <T extends undefined>(x: (() => void) | T) => () => void
var f4: <T extends undefined, U extends undefined>(x: (() => void) | T, y: (() => void) | U) => () => void

var f3 = <T extends undefined>(x: (() => void) | T) => x && (() => x());
>f3 : <T extends undefined>(x: (() => void) | T) => () => void
>   : ^ ^^^^^^^^^         ^^ ^^                ^^^^^^^^^^^^^^^
><T extends undefined>(x: (() => void) | T) => x && (() => x()) : <T extends undefined>(x: (() => void) | T) => () => void
>                                                               : ^ ^^^^^^^^^         ^^ ^^                ^^^^^^^^^^^^^^^
>x : T | (() => void)
>  : ^^^^^^^^^^^    ^
>x && (() => x()) : () => void
>                 : ^^^^^^^^^^
>x : T | (() => void)
>  : ^^^^^^^^^^^    ^
>(() => x()) : () => void
>            : ^^^^^^^^^^
>() => x() : () => void
>          : ^^^^^^^^^^
>x() : void
>    : ^^^^
>x : () => void
>  : ^^^^^^    

var f4 = <T extends undefined, U extends undefined>(x: (() => void) | T, y: (() => void) | U) => x && y && (() => { x(); y() });
>f4 : <T extends undefined, U extends undefined>(x: (() => void) | T, y: (() => void) | U) => () => void
>   : ^ ^^^^^^^^^         ^^ ^^^^^^^^^         ^^ ^^                ^^ ^^                ^^^^^^^^^^^^^^^
><T extends undefined, U extends undefined>(x: (() => void) | T, y: (() => void) | U) => x && y && (() => { x(); y() }) : <T extends undefined, U extends undefined>(x: (() => void) | T, y: (() => void) | U) => () => void
>                                                                                                                       : ^ ^^^^^^^^^         ^^ ^^^^^^^^^         ^^ ^^                ^^ ^^                ^^^^^^^^^^^^^^^
>x : T | (() => void)
>  : ^^^^^^^^^^^    ^
>y : U | (() => void)
>  : ^^^^^^^^^^^    ^
>x && y && (() => { x(); y() }) : () => void
>                               : ^^^^^^^^^^
>x && y : U | (() => void)
>       : ^^^^^^^^^^^    ^
>x : T | (() => void)
>  : ^^^^^^^^^^^    ^
>y : U | (() => void)
>  : ^^^^^^^^^^^    ^
>(() => { x(); y() }) : () => void
>                     : ^^^^^^^^^^
>() => { x(); y() } : () => void
>                   : ^^^^^^^^^^
>x() : void
>    : ^^^^
>x : () => void
>  : ^^^^^^    
>y() : void
>    : ^^^^
>y : () => void
>  : ^^^^^^    

The compiled JS output (with no compilation errors) is as follows:

var f3 = function (x) { return x && (function () { return x(); }); };
var f4 = function (x, y) { return x && y && (function () { x(); y(); }); };

If this is incorrect, please let me know! I’m still in the process 😅

[zeng-y-l]

@976520

I want f3 to return T | (() => void) and f4 to return T | U | (() => void), otherwise f3(undefined) will be typed () => void.

I don't know why, but changing a && b to a ? b : a solves this problem. I think they should have the same behavior.