Design Meeting Notes, 11/06/2015

[RyanCavanaugh]

String literal types (#5185, #5156, #1003)

• These types describe values that can be of certain literal values
• They are introduced on to string literals via contextual typing
• Very similar to enums in their semantics
• Compared using string equality (case-sensitive, escaping/etc does not matter)
• What's the difference compared to string enums?
  • Less complex
  • We don't need symbolic names for strings like we do for numbers
  • Does not introduce branding of the constituents in the same way
• What is the future of enums?
  • e.g. string values?
  • Not clear that e.g. var x: 0|42|88; is a use case
• We could show these string literals in completion lists
• Does this work for consolidating string overload sets (e.g. MouseEvent) ?
  • Yep (e.g. function onEvent(name: "click|drag|move")): void;)
• Why isn't the type of uncontextually-typed 'foo' === 'foo' ?
  • Why can't we solve this through widening?
  • Can we solve this by making union types of string literals be StringLike?
  • Acceptable leak to allow "foo"|"bar" === "baz"|"thing"
• Does this have any explicit logic about narrowing?
  • No
• Open questions
  • Should we add these to type guards?
    • What value does that add?
      • Useful only in the "removing from a union" case
  • ADTs of type guards (see Anders' first comment in Singleton types under the form of string literal types #1003)
    • Would this fall out of a correct implementation of string literal type guards + property-based type guards?
    • Also add enum value types in a future PR
  • Which comes first - enum values or property-based narrowing?
    • Whichever
  • Outcome: Approve enum-value types and property-based type guards. Issue #s to follow.

Comparable relation (#5300)

• What do we need this for?
  • Example: var x: "foo"|"bar"; if(x === "foo") { ... }
  • Mostly string types (String literal types #5185) and enums
• Why do we need a new relation?
  • Some solution is needed
  • But this is overkill
    • Has issues with perf due to a lack of caching
• Agreement that this is the desired behavior
• Move implementation to the operand logic
  • But this loses recursiveness
  • Is that desirable?
  • Recursiveness is not obviously correct here; top-level should be sufficient
  • Not clear that anyone has run into this
• Which is preferable -- adding the extra cache or having this weirdish logic in multiple places?
• Does implementing this at operator level solve the use cases?
  • Probably?
• Decision: Move this logic to the operators, do not add a new relation

Module file extensions

• Question for Brian - file extensions on modules?
  • Module loader WG has said you must write from "foo.js" instead of from "foo"; system.js has implemented this behavior
    • This is only for the browser, not node -- non-browser implmentors might do other stuff
  • But people want to write code that runs in both places. What are they supposed to do?
  • Is the fix to have packagers (e.g. browserify) modify the filenames during transform?
    • Maybe
    • But that is ridiculous. Bifurcates the world when it used to be platform-agnostic

[basarat]

For string literals (unleashed upon the world), would definitely like autocomplete and (rename refactoring does it make sense?)

type Foo = "aReallyLong" | "bReallyLong"; // allow me to rename these
let foo:Foo;
foo = "aReallyLong"; // allow me to autocomplete these

[mhegazy]

@basarat would you mind filing a separate issue for this?

[basarat]

created two issues / feature requests 🌹