Narrowed type information is **sometimes** lost in callback functions.

[yudai-nkt]

Bug Report

🔎 Search Terms

type narrowing, callback

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about type guards.

⏯ Playground Link

Playground link with relevant code

💻 Code

type Option = { isSome: true, value: unknown } | { isSome: false };

export default (
  foo: Option,
  bar: { baz: Option },
  qux: (arg: unknown) => unknown
) => {
  if (foo.isSome) {
    foo.value;
    qux(foo.value);
    [].map((_) => foo.value);
  }
  if (bar.baz.isSome) {
    bar.baz.value;
    qux(bar.baz.value);
    [].map((_) => bar.baz.value);
  }
};

🙁 Actual behavior

The line [].map((_) => bar.baz.value); does not compile, inferring bar.baz to be of type Option. I thought it was narrowed down to { isSome: true, value: unknown } just like the above two lines.

🙂 Expected behavior

The aforementioned line should compile as I explained in the last section.

The closest documentation to the situation of my problem is this issue template, which says:

narrowings are not respected in callbacks. In other words:

function fn(obj: { name: string | number }) {
  if (typeof obj.name === "string") {
    // Errors
    window.setTimeout(() => console.log(obj.name.toLowerCase());
  }
}

This is intentional since the value of obj.name "could" change types between when the narrowing occurred and when the callback was invoke [sic].

This might make sense, but does not seem to explain why [].map((_) => foo.value); compiles. I don't see why foo.value and bar.baz.value in callbacks produce different results, so I opened this issue.

[fatcerberus]

This is indeed a duplicate of #9998, per the mentioned issue template. The narrowing of foo is retained due to a carve-out in control-flow analysis for direct parameter bindings which are not modified anywhere in the containing function. That exception doesn't extend to general variables or object properties, though.

[yudai-nkt]

I'm not sure if I understand the last sentence. Do you mean supporting bar.baz.value here is technically hard and is not implemented? A guess from the word "curve-out".

[fatcerberus]

Yeah, it's a specific exception made for function parameters because the compiler knows that if the parameter isn't reassigned anywhere inside the function, its value can't possibly change. As a general rule though, type narrowing isn't retained across function boundaries, and that's a deliberate design decision. The reasons why and possible alternatives are discussed in #9998; it's a very hard problem to solve.

[yudai-nkt]

It's a long thread but I'll read it thoroughly later, thanks!