Design Meeting Notes, 9/28/2015

[RyanCavanaugh]

Exponentiation operator

• Has reached Stage 3 ES7 proposal
• Always compiles to Math.pow call
• Open questions on the precedence relative to -
• 👍

---

this type

What is the behavior of this inside an object type literal?

e.g.

interface Foo {
  x(): { b: this }
}

• Error to avoid ambiguity. Multiple people have strong opposite opinions on what this would mean
• Workaround is to enclose in a generic

interface X<T> {
  (): { b: T }
}
interface Foo {
  x: X<this>;
}

What about type aliases for this?

• No local type aliases in class/interfaces for now, especially for this

What is the .d.ts emit for this?

class C {
  f() { return { x: this } }
}

• Either error, or emit the imprecise type { x: C }?
  • Error. Breaking change but unlikely in practice.
• Updates to lib.d.ts are in progress (e.g. Array#slice which will help with tuples)

---

Module bundling and feature selection

How do we support ES6 constructs compiling for non-ES6-module-supporting hosts (e.g. nodejs) ?

• Wesley has a PR that fixes this
  • Do we need to break apart all features for maximum granularity?
• First take: No. Combinatorial explosion of options is bad.
• But ES6 support is actually a moving target
• Even when ES6 finishes, we will be in the same boat for ES7
• Regardless, we need a "remove TypeScript-specific stuff" (--target next ?) that gives us an ES7-ready JS file for fully-compliant runtimes

PR ready for "self-extracting modules" which have no external module dependencies themselves (#4434 / #4754 )

• Why not browserify? -> It still leaks some of your implementation surface -> should anyone actually care?
• Considering our own use case as motivating scenario
• [long discussion of how self-extracting modules should work and whether a microloader is needed]
• Need to define which cases browserify/webpack/etc don't handle

Multi-file external modules through re-exporting

• What if we flatten re-exports of external modules? Useful for hiding implementation details and exposing a uniform API surface
• How would you specify the "base" module? Via commandline option
• One compilation pass per surface area is acceptable to some
• Angular wants it
• Is this actually useful to anyone? i.e. could anyone who would want to use this not be blocked by some other thing? Tools could combine these files for us anyway with better configurability, or hand-writing is still acceptable
• What would justify adding this feature?
  • Getting Angular on an full build pipeline? Probably not going to happen
  • What does the average TypeScript user want? Average user is not encountering this
  • Module bundling for library authors is different from module bundling for end-users
  • People keep wanting to merge namespaces across external modules, for some reason
  • Are .d.ts files supposed to be 100% human-friendly?
  • Letting other tools decide these complex policy questions is a better way forward

[jbondc]

Are .d.ts files supposed to be 100% human-friendly?
I'd say yes.

What does that have to do with modules / justify adding the feature?

[mhegazy]

The feature is mainly to make the .d.ts look simpler/cleaner. it is possible to write a tool that will remove declarations from the file, but it is not 100% human-friendly

[RyanCavanaugh]

(whatyearisit.jpg)