`null`/`undefined` guards sometimes adds `& ({} | undefined`/`& ({} | null` (out of nowhere) to the tested variable.

[denis-migdal]

🔎 Search Terms

guards
null undefined
type narrowing
generic function
type inside generic function

Searched for related issues, didn't found any.
Maybe this issue is somehow related to the type narrowing system ?

🕗 Version & Regression Information

• This is the behavior in every version I tried.

⏯ Playground Link

Playground Link

💻 Code

See playground for full example.

type Hook  = (...args: any[]) => any;
export type Hooks = Record<string, Hook>;

function foo1<T extends WithHooks<any>>() {

    type Hooks = GetHooks<T>; // but works if in the generic template.
    const hook = {} as Hooks[keyof Hooks]; // type: GetHooks<T>[keyof GetHooks<T>]
    if( hook === undefined)
        return;

    hook(...null as any); // nok: adds '& ({} | null)' to the type.
}

🙁 Actual behavior

Somehow TS adds & | ({}|undefined) or & | ({}|null) to my type as if it was narrowing from & ({} | undefined | null)... but where does this type would come from ???

If I test with hook === false and ! hook, the type isn't modified (cf playground). Also tested with typeof === "object", === 2, === "2", and with a personalized type guard is {}. Seems to only occurs when testing with undefined and null.

I understand that conditions sometimes breaks type narrowing, but I shouldn't have type narrowing here, right ?

🙂 Expected behavior

The type shouldn't change.

Additional information about the issue

Found this issue by accident.
Declaring a type inside a generic function isn't recommended, so this issue shouldn't have a big impact.

Still, this behavior quite surprises me, and might cause issues in other contexts (or be the cause of other strange behaviors).

Note: an easy workaround is to put the type definition inside the function generic types:

function foo5<T extends WithHooks<any>, MyHooks extends Hooks = GetHooks<T>>() {

    const hook = {} as MyHooks[keyof MyHooks];
    if( hook === undefined)
        return;

    hook(...null as any); // ok
}

[MartinJohns]

• This is the behavior in every version I tried.

The playground makes it so easy to test various versions... It was easy to find out (on a mobile phone within minutes) that it changed in version 4.8, which leads you to: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-8.html#improved-intersection-reduction-union-compatibility-and-narrowing

So it's working as intended.

[denis-migdal]

Please, don't be passive-aggressive.
I spent lot of time reducing my issue to a minimal reproductible exemple, tweaking stuff to see what influence what.
I also tested several versions from 6.0.2 to ~5.2 to see if it was a recent regression. True, I could have made a binary search to be quicker instead of testing each version.

Thanks for your message, though.
However, I do not see where we could assume that this is working as intended (cf hypothesis below).

Hypothesis 1: this comes from the & {} on undefined/null guards.

But then, why do I have & ({}|null) and not just & {} ?
And why does the issue disappear if I move the type definition to the generic parameters ?

Hypothesis 2: & ({}|null) coming from a & unknown.

But then, where would this unknown be coming from ?
Even if my type was somehow Hook & unknown, this doesn't produce this behavior:

type T = (() => void) & unknown; // this is () => void.
const x = {} as T;

if( x === undefined ) throw "ok";

x // still () => void

Even when using a generic:

function foo<T extends () => void>() {
    
    const x = {} as T & unknown;

    if( x === undefined ) throw "ok";

    x // still () => void
}

Or on more complex exemple:

type X<T> = {foo: T};

function foo<T extends () => void>() {
    
    type Z = X<T>;
    const x = {} as Z & unknown;

    if( x === undefined ) throw "ok";

    x.foo() // still () => void
}

[denis-migdal]

Okay, I think I got where the behavior comes from:
Playground Link

// do now works
function faa<T extends X<any>, Z extends any = GetC<T>>() {

    const x = {} as Z;

    if( x === undefined ) return;

    x()
}

// works
function foo3<T extends X<C>>() {
    
    type Z = GetC<T>;
    const x = {} as Z;

    if( x === undefined ) return;

    x()
}

The question is, when we use X<any> with any, should TS really use any for Z type definition, i.e. Z extends any = GetC<T> instead of the generic parameter constraint of X, T extends C, i.e. Z extends C = GetC<T> ?

Normally we shouldn't (and shouldn't be able to) give a type to X that doesn't respect the constraint. When we write any in that context we intend to say "anything that matches the constraint".

Not sure if this is really intended, or an oversight.

[MartinJohns]

But then, why do I have & ({}|null) and not just & {} ?

Because when you narrow by "not-undefined" , the value still might be null. Or might be any non-null/non-undefined value, which is {}. So it's null | {}.

But then, where would this unknown be coming from ?

Unbound generic type.

Even if my type was somehow Hook & unknown, this doesn't produce this behavior:

Hook & unknown is the same type as Hook, so no unknown involved.

[denis-migdal]

Unbound generic type.

It does not feel to be unbound to me. To the contrary, after some test, it seems defined as something as:

Z extends GetC<X<any>> = GetC<T>

Indeed, if we use extends X<C> we then get something that looks like:

Z extends GetC<X<C>> = GetC<T>

Then should TS really use any when we use extends X<any>, instead of using the constraint defined in X ?

[denis-migdal]

I took a look at the behavior of X<any>.

Is giving any to a constrained generic type parameter to be discouraged ?
In this case, should TS have an option to warn us when we do it ?

But in this case this would mean we'd have to replace the extends X<any> by:

• extends X if defined as X<T extends C = C>, but that'd mean we won't be able to use the default for other usages.
• extends X<C>, but that'd mean writing it everywhere, and knowing the type to use.

For the second solution, this can quickly be a pain if we have some type depending on another, depending on another, etc. having to write extends X<C<D<E<F<number>>> instead of simply extends X<any>, even worse if we have some circularity.

What is the stance of TS on extends X<any> ?

[denis-migdal]

Playground Link

type X<T extends string> = {foo: T};
function foo<T extends X<any>>(t: T) {}

foo({ foo: 23 });

Hum...

Then could we have:

• a * keyword we could use in place of any that would mean "the type of the constraint", i.e. T extends X<*> would mean extends X<string> ?
• a ** keyword that would be equivalent to *, *, *, *..., i.e. X<**> could mean X<*>, X<*,*>, etc. depending on the number of X's generic parameters.
• a compiler option to detect explicit any given as generic parameters. Indeed, lot of us are currently writing extends X<any> but this is in fact dangerous.

Note: a third workaround:

type AnyX = X<string>;

function foo<T extends AnyX>(...) { ... }