Design Meeting Notes, 07/22/2016

[RyanCavanaugh]

• Number, enum, and boolean literal types #9407 Number / enum / boolean literals
  • New concept: Unit type
    • A type with a single value (e.g. null, undefined, true)
    • e.g. Boolean is a union of the two unit types true and false
    • e.g. enums are unions of their constituent unit types corresponding to each member
  • Literal types are subtypes of their respective primitives, of course
  • When do we treat a string literal as its literal type vs its string type?
    • Literal type locations
      • An operand of an equality operator is a literal type location
      • As are case labels
      • Basically same rules as contextual typing in terms of flow
      • A location is a literal type location when assigning or comparing to a literal type
  • Old behavior: === operator would narrow based on null / undefined
    • New behavior: Narrowing works on constituents of unions of literal types
    • Bidirectional, e.g. string | boolean === string | number produces string for both operands
  • Control analysis works on unit types in switch blocks
    • Understands case fall-through
    • Can narrow down to never for exhaustiveness
  • Fun things now possible
    • { hasValue: true; value: string } | { hasValue: false } instead of { hasValue: boolean; value?: string }
  • Narrowing now applies to discriminator properties of unions
    • Removes many type assertions in the compiler
  • Inference of flag-like enums based on initializer expressions
    • No narrowing or unit types for enums that look like flags
    • Possible confusion since e.g. enum X { a = 1 << 0, b = 1 << 1 } different from enum X { a = 1, b = 2}
  • Open question: How to represent functions with side effects over locals
  • PR includes perf work
    • Shortcut: return early when checking T assignable to U when T is a constituent of U by object identity
    • Reduce closure allocations in isTypeRelatedTo
    • Remove O(n^2) duplicate removal algorithm
    • Be smarter about subtype reduction during union type construction -- do this rarely, not eagerly!
    • Union types are now ordered by ID to guarantee correct type identity when re-merging union types
  • Which release should this go into?
    • master, review feedback, then possibly 2.0 branch
    • Port perf fixes to 2.0 for sure