Function declarations inside function expressions should inherit control flow narrowings of the parent function expression

I am trying to avoid typing null checks for properties that are formerly optional on the outer interface, but are then assigned with default values for the whole context of the function body.

I used a type guard for it, the problem is that the guarded type is lost in a function, but not lost in an arrow function, even though it can't be hoisted before the type guard.

I don't want to introduce new variables for every function parameter in a similar manner and I don't want to call other functions with casting as printMenu(options as DefinedOptions).

TypeScript Version: 3.7.3, 3.8.0-beta

Search Terms:
typescript type guard function arrow function
Code

export interface Options {
  header?: string
  border?: boolean
  pageSize?: number
  helpMessage?: string
  showKeypress?: boolean
}

interface DefinedOptions extends Options {
  pageSize: number
  helpMessage: string
}

const isType = <T>(arg: any): arg is T => true


export default async function menu(options: Options) {

  options // Options

  options.pageSize = options.pageSize ?? 0
  options.helpMessage = options.helpMessage ?? 'Default message'
  if (!isType<DefinedOptions>(options)) return null


  options // DefinedOptions


  return new Promise((resolve, reject) => {

    function handleMenuKeypress(key: any) {
      options // Options  -  should be DefinedOptions

      printMenu(options) // error
    }

    const candleMenuKeypress = (key: any) => {
      options // DefinedOptions

      printMenu(options) // no error
    }
  })
}

function printMenu(options: DefinedOptions) {

}

Playground Link

Expected behavior:

Type should be DefinedOptions in both.

Actual behavior:

Type is Options in function but DefinedOptions in arrow function.

Related:
#10927

This is a simplified form of what you're looking at:

interface A { s: string }
interface B extends A { t: boolean }

declare function isb(a: A): asserts a is B;

function foo(a: A) {
  isb(a);
  a; // B
  const f = () => {
    a; // B, since f is not hoisted and couldn't be called before its definition
  }
  function g() {
    a; // A, since definition of g is hoisted and could be called elsewhere
  }
  const h = () => {
    a; // B
    const hf = () => {
      a; // B
    }
    function hg() {
      a; // A, hg is hoisted but it couldn't be called ouside of h?
    }
  }
}

Playground

I'd say that typescript is being overly pessimistic in the case of a regular function declaration inside of an arrow function, and that hg should have the same narrowing that's present in h, even given what's discussed in #32300.

nmain100

Thanks for the simplified version nmain100

The only bug here is hg - it should be B given its position in the CFA graph. Function expressions and function declarations behave differently because one is hoisted and the other isn't.

is it the same bug as:

function somethingWentWrong(): boolean {
  let definitellyIsTrue: boolean = false;
  ['true'].forEach(() => { definitellyIsTrue = true });
  return definitellyIsTrue == true;
}

console.log(somethingWentWrong());

Playground Link

If you run it with playgroynd you find error "This condition will always return 'false' since the types 'false' and 'true' have no overlap.(2367)"

Or I need to make new issue for this?

Aleksandr Gilmanov (@AleksandrGilmanov)

Aleksandr Gilmanov (@AleksandrGilmanov) That's a duplicate of #9998; typescript doesn't know that the function passed to forEach is called at that point, and if all narrowings were pessimistically reset after every function call, narrowing would be mostly useless.

Another standard case:

function foo(opts?: object) {
  opts = opts || {};
  opts; // object
  return () => opts; // object | undefined <- wrong
}
function bar(a?: string | object, opts?: object) {
  if (typeof a === 'object') [a, opts] = [undefined, a];
  a; // string | undefined
  return () => a; // string | undefined | object <- wrong
}

http://www.typescriptlang.org/play/?ts=3.8.0-dev.20200124&ssl=1&ssc=1&pln=10&pc=2#code/GYVwdgxgLglg9mABMOcAUcAOUDOB+ALkTgCMArAU2gEpEBvAKEWOx0QF4XdEAfH+gL4BuJlxxDEAeknFyVKKIBOFKCEVI0tdgD4xE6bMrReicABMKwGGApnEAHgC0iAO6KEAcwYCGoSLAREEgBDRTRgwkQcKEVrDxNSIygAGjFIxPlaRmYYYEQ0KABPTAo4POCOdk4AcgzoatoAbWDUrFwAXQ5ERvNLa1tU4PaRZmD9GWjYsHj+XqsbMyUVNQ0tXTGpCZi4kzn+u346qAdnN09vIA

Hello there!

Could anybody take a look at this playgroud, please? I left appropriate comments about an error at the bottom of the file. It seems that my issue is partially related to this one, though it is not about function types (function declaration or function expression).

Should I create a separate issue or they are related?

Thanks in advance.

extra local assignment to workaround typescript bug

Some other update must have resolved this partially because I get the following on 4.5.4:

function workingExample<T>(
    arg: unknown,
    validator: (arg: unknown) => asserts arg is T,
    callme: (arg: T) => void
): void {
    validator(arg);
    const fn = () => {
        callme(arg); // no error. arg: T
    };
}

This seems like the original issue. However, when asserting a member of an obj, it still fails, but very confusingly. The type comments are coming from VSCode hover on TS 4.5.4:

function nonworkingExample<T>(
    arg: {member: unknown},
    validator: (member: unknown) => asserts member is T,
    callme: (member: T) => void
): void {
    validator(arg.member);
    callme(arg.member); // no error. on hover -> arg: {member: unknown}, but arg.member: T ???
    const fn = () => {
        callme(arg.member); // error. arg.member: unknown
    };
}

Edit: Found a work-around for now which is fine I guess:

function woraround<T>(
    arg: {member: unknown},
    validator: (member: unknown) => asserts member is T,
    callme: (member: T) => void
): void {
    const member = arg.member;
    validator(member);
    callme(member); // no error. member: T
    const fn = () => {
        callme(member); // no error. member: T
    };
}

Optimize binding pattern emit for variable creation (#2946)

Navigation Menu

Repository navigation

Function declarations inside function expressions should inherit control flow narrowings of the parent function expression #36436

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Function declarations inside function expressions should inherit control flow narrowings of the parent function expression #36436

Description

Activity

nmain100 commented on Jan 27, 2020

RyanCavanaugh commented on Jan 27, 2020

AleksandrGilmanov commented on Jan 29, 2020

nmain100 commented on Jan 29, 2020

falsandtru commented on Feb 6, 2020

vasilii-kovalev commented on Apr 27, 2020

mheripsos commented on Jan 11, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions