Implicitly typed type guard does not guard

[OldStarchy]

🔎 Search Terms

"never type guard", "never returning function does not guard", "type guard parameter"

🕗 Version & Regression Information

Tested in the playground on major versions 4.0.5 to 6.0.3, same for all.

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=6.0.3#code/GYVwdgxgLglg9mABAcwKZQOIgIYCcAmAPACoB8AFMGAFyLkBG2MANreQJSIC8piYqAN1S5OPRMXa1iiAN4AoRIlzoQuJFXIduvGYigALXHADuiAXBj5EABgDciAL7tbch3LmhIsBIhgBbAAdmGAgYKHIBbFZZPWxkWgBybAT7bFoAZyhcGDBkR0QAHxioOMT6BIAaRHpaMBA-emFHTnlFZShVJDRMHAJNRhZRHQVFX2A6SOYAOhK8ri5EJITOAeYOFxG2lTUzKKn6ewB6Q8RwVAAPANRoVCthI1wRp1d3T2h4JAugkLCIqNpdLNEslUhksjk8g5CsVSotylUanx6o1cM1ZCN2p0UOgsHh8P0mNEtGJ+EIRNp0aMxhM9rNuAslitCet3FTMTtJvsjic4ABrJ7sF5yCAITK7aKA2FLUGITLZXL5IqS+JwyrVWrIppQhbKspqxEAFkcwtFUEQ2G4vkCwVC4UmzkQx3NYAAniawGL6JavjbfvbuUiGsIgA

💻 Code

A parameter explicitly typed as () => never can be used as a type guard, but one with an implicit type () => void does not.

function getGuard<T>(fn: (bail: () => never) => T): T {
  return fn(() => { throw void 0; });
}

function implicit(val: { tag: 'a'; a: string } | { tag: 'b', b: number }) {
  return getGuard((bail) => {
    if (val.tag == 'a') bail();

    return val.b; // unexpected error
  })
}

function explicit(val: { tag: 'a'; a: string } | { tag: 'b', b: number }) {
  return getGuard((bail: () => never) => {
    if (val.tag == 'a') bail();

    return val.b; // ok
  })
}

const val: { tag: 'a'; a: string } | { tag: 'b', b: number } = { tag: 'b', b: 4 }
const a = implicit(val); // any
const b = explicit(val); // number

🙁 Actual behavior

The type is not narrowed after invoking a never-returning function in an if block

🙂 Expected behavior

The type is narrowed the same way that it does for an explicitly typed guard, a throw, or a return etc..

Additional information about the issue

No response

[MartinJohns]

This is working as intended. See #32695:

A function call is analyzed as an assertion call or never-returning call when

• the call occurs as a top-level expression statement, and
• the call specifies a single identifier or a dotted sequence of identifiers for the function name, and
• each identifier in the function name references an entity with an explicit type, and
• the function name resolves to a function type with an asserts return type or an explicit never return type annotation.

[OldStarchy]

I'll spend some time to read through that linked issue, but I'm tempted to suggest now that this is either

• not the same as that issue; I'm not using an asserts type guard. bail will always throw.
• or that I need to raise a feature/change request rather than a bug request, because it does not (yet) make sense to me why these two identical functions should be treated differently by the engine, especially since they're both rendered as const bailX: () => never in the tooltip.

const bail1: () => never = (()        => {throw void 0;});
const bail2              = (()        => {throw void 0;}) as () => never;
const bail3              = ((): never => {throw void 0;});

type TypesEqual<A, B> = [A, B] extends [B, A] ? true : false;

const same12: TypesEqual<typeof bail1, typeof bail2> = true;
const same13: TypesEqual<typeof bail1, typeof bail3> = true;
const same23: TypesEqual<typeof bail2, typeof bail3> = true;

function fn1(val: { tag: 'a'; a: string } | { tag: 'b', b: number }) {
  if (val.tag == 'a') bail1();

  return val.b;
}

function fn2(val: { tag: 'a'; a: string } | { tag: 'b', b: number }) {
  if (val.tag == 'a') bail2();

  return val.b; // unexpected error
}

function fn3(val: { tag: 'a'; a: string } | { tag: 'b', b: number }) {
  if (val.tag == 'a') bail3();

  return val.b; // unexpected error
}

const val: { tag: 'a'; a: string } | { tag: 'b', b: number } = { tag: 'b', b: 4 }
const a = fn1(val); // number
const b = fn2(val); // any
const c = fn3(val); // any

[MartinJohns]

• not the same as that issue; I'm not using an asserts type guard. bail will always throw.

See this part: "or never-returning call"

that I need to raise a feature/change request rather than a bug request

This limitation is for performance reasons.

In both your examples this intentional requirement is not fulfilled:

each identifier in the function name references an entity with an explicit type

[OldStarchy]

I see. While I don't know what "Performance reasons" underpin this restrictions, I understand that the type inference system is complicated, and I'll have to trust you when you say it. That said, if there's a wishful thinking backlog perhaps this use case is simple enough for never-returning methods that already have their types resolved/inferred.

Here's a snippet closer to my concrete use case for anyone interested.

function deserialize(obj: unknown): Result<Foo, Error> {
  return Result.withBail((bail) => {
    if (typeof data !== 'string') bail(new Error('not a string'));

    return new Foo(JSON.parse(data));
  });
}

const foo = deserialize('1234').unwrapOrElse(bail) satisfies Foo;

the workaround will have to be Result.withBail((bail: (err: Error) => never) => { or Result.withBail((bail: Bail<Error>) => {

[MartinJohns]

While I don't know what "Performance reasons" underpin this restrictions, I understand that the type inference system is complicated, and I'll have to trust you when you say it.

I don't know the details myself, I just repeat what the team (which I am not a part of) has said in the other issues. Digging through the PR and the related issues (search for never in:title) you'll surely be able to find a detailed explanation.

That said, if there's a wishful thinking backlog perhaps this use case is simple enough for never-returning methods that already have their types resolved/inferred.

The team is definitely aware of this annoying restriction. Who knows, perhaps with the new native compiler it might be an option to take another look at it. Maybe Ryan can answer this when he labels / closes this issue.

[jcalz]

As a feature request, this would duplicate #45385 (which is a good read for people who run into this situation).

[RyanCavanaugh]

It's not just performance (even if it were, the point of a faster compiler is to be faster, not have more features and then be something that people complain about being slow again). Type circularities are always a possible side effect and ones that frequently cause complaints too.

Imagine you had something roughly like

let value = "hello";
const installListener = function() {
    addEventHandler(() => result);
}
installListener();
const result = value;

where there aren't CFA implications of installListener, but now analyzing it introduces a type circularity on result because we have to check for the reachability of that statement during type resolution of result. Worse - how do you get out of this one? Forcing you to annotate result is really annoying, as is forcing you to annotate installListener. Pushing "must annotate" burden to CFA-affecting symbols minimizes the damage.