Design Meeting Notes, 4/29/2016

[mhegazy]

Control flow -- IIFE's and calls (#8381):

IIFE's :

• we can not do it correctly everywhere

• our assumptions are too conservative specifically for lambdas and function expressions

• For function expressions and lambdas, can get the same control flow of their syntactic container.

• Proposal:

  • Assume that at the entry of a function expression or a lambda that the previous control flow holds
    example:

  var x: number | undefined;
  x = 0;
  foo(() => { x }) // treat x as number here

  • Control flow after the function be impacted by the body of the function the same way as an conditional statement, as you make the assumption that the function ran 0 or n times at this position.
    example:

  var x : number| undefined;
  x; // undefined
  foo(()=>{
  x = 10;  // x is a number here 
  });
  x; // number | undefined

  • async functions would have the same semantics like a lambda or a function expression

what to do with delayed initialization

• example

  let value: number | undefined;
  
  initialize();
  
  if (value !== undefined) {
  value++; // Error value is of type nothing!
  }
  
  function initialize () {
  value = 1;
  }

• The ideal solution here is to inline the function body of initialize at the call site, and do the control flow analysis as if the body of the function was in the same scope. obviously you need to make sure parameters are mapped correctly, scopes, etc.

• issue referenced in Suggestion: control flow type analysis could account for reassignments through a closure #8353

• this is too complex

• on the other hand the error is not useful

• possible solution, rewrite the code to use an assertion instead of a declaration

let value = <number | undefined> undefined;

value; // here value is number|undefined

• this is not intuitive.
• Proposal
  • consider the type guard as an assertion and not just as a narrowing operation
  • the type you are asserting is part of the declared type, then use that instead of narrowing
  • this is similar to how we treat instanceof guards

Contextually type implemented properties

• PR: https://github.com/Microsoft/TypeScript/pull/6118/files
• Proposal:
  • A class property "inherits" the type of the property in a base class or an interface it implements,
  • The initializer is then checked against that type
• Next steps
  • Run the RWC tests on the proposed change and see what patterns this would break.