This project is read-only.

TypeScript Design Meeting Notes: 4/18/2014

Topics: Language Specification
Apr 25, 2014 at 4:53 PM
  • Update on ES6 module discussions
  • Module resolution algorithm
  • __extends and its optional inclusion
  • ES6 alignment:
    • Symbols and the type system improvements to support them
    • Proxies and the type system impact (if any)
    • ES6 classes
  • How do we want to handle 'extends' of an expression?
  • Should get/set be reflected in the type system?
Updates from ES6 committee

ES6 Modules

There's a potential new ES6 module syntax change currently under consideration. Rather than using the 'module' keyword for loading the default module, the committee is considering a simplification that uses import. Example:
import $ from "jQuery";  // export default loader
import {ajax} from "jQuery"; // exported member loader
This should fit into the existing TypeScript syntax.

A question came up about what is the object representation of the ES6 module. You can get to a reflected object representation using Module. The result has getters that can reach into the reflected module.

Questions that came up in discussion:
Schedule-wise we could start implementing in earnest soon. July still sounds like "pencils down" for the ES6 spec, which is only a couple months away. Expect that most of the syntax is pretty settled at this point.

Updates on ES7

Interesting proposals coming down the pipeline that we may want to explore as they mature:
  • Decorators/annotator straw man
  • async/await
  • ParallelJS
Module resolution algorithm

Question: The TypeScript module resolution algorithm is shares similarity to both AMD and node, but it doesn't allow any specialization for the kind of module loading/configuration that loaders like Require, Common, and others might want to do. This may continue to grow, with ES6 adding yet another type of loading into the mix. One user wants to extend our process: What is the best approach to enable growing and changing as module loaders evolve?

Supporting all the module loaders natively doesn’t seem like the best approach. A better approach would be to enable a pluggable resolver architecture that allows people to plug into the compiler a new ways of resolving module names to their associated files. This would allow them to look into configuration files and to parse templated module names.

Action item: Let's research this more deeply to see what a pluggable loader would work like.


Question: The __extends function is one of the only places in the compiler that we inject code into what the user provided. Would be nice to be able to suppress this and allow the user to assume the responsibility of providing their own. We would also suppress in the case of ES6 output, once that's added. Do we want to enable the ability to opt-out of this codegen? If so, how?

We already allow users to create a user-defined __extends function. When they do so, we do not redefine it (codegen uses this.__extends || function(d, b) { …. } to prevent redefinition). Do we want to go a step further?

Proposed Solution: Check if there is any global symbol __extends in the user code, even if it's a declare symbol. If we see it, we don't emit our own __extends. We may want to check that the type of the provided __extends matches the shape of the one we will expect to call.

Aligning with ES6


Question: ES6 is adding a new basic type that allows a unique key into objects called a ‘Symbol’. We currently don’t have a way of capturing the uniqueness of each Symbol type. How do we want to describe symbols in the type system?

We need to introduce a new basic type for symbols which can be used as a new kind of key into objects.

Take as an example [Symbol.iterator]
var x = {  [Symbol.iterator]: value };
Where does the Symbol.iterator get the value that's used as the key? Is this something we track in the type system? Are each symbol type fresh? We could introduce a notation 'new Symbol' as annotation for creation a fresh new symbol type.
declare var Symbol: {
    iterator: new Symbol;
var I = Symbol.iterator;
How does this relate to existing type rules? Is a new fresh type like creating a new enum on the spot?

The indexes would gain a new 'symbol' indexer. We would use syntactic sugar to be able to reference the symbols through the common ES6 name (which we would have typed ahead of time in lib.d.ts for the common symbols):
interface Foo {
   [x: string]
   [x: number]
   [x: typeof Symbol.iterator] : FooBar  // use of symbol indexer type
   [Symbol.Iterator]: FooBar // short form of the previous line
We need to continue investigating to better understand the implications of having symbols be unique types.

Action item: explore the trade-offs of the ‘fresh type’ design and report back to next design meeting.
Proposed min bar for the design: for-of needs to have the item type strongly typed.
Apr 25, 2014 at 9:18 PM
Thanks for posting this. It's nice to see what's current on then radar for this project.
Apr 26, 2014 at 1:51 AM
Agreed - this is great - thanks for giving insight into some upcoming changes.
Apr 26, 2014 at 8:42 AM
Great to see this - thanks for posting.
Apr 27, 2014 at 12:26 PM
Edited Apr 27, 2014 at 12:35 PM
Very glad for this insight into the design meeting.

Providing clarity around the internal workings of TypeScript is likely to reduce the risk that people associate with adopting the new language.

More information on upcoming releases - especially with regard to release dates - would also be very helpful for project managers in the real world.
Apr 27, 2014 at 5:02 PM
I agree - nice to have insight behind the scenes. I suddenly feel part of the team reading this. ;)
Apr 28, 2014 at 4:32 PM
Thanks all. Now to see if I can keep this up. Feel free to bug me if they drop off.

Please also feel free to jump in and comment. We regularly talk about topics that come up in forum posts as part of the design meeting. If we catch a design that needs some improvement early on, that's always better than after it's implemented.

@nabog - I'll try to put together a roadmap and get that posted, though this is "conference season" for us, so it may take a little bit longer. We don't tend to talk dates, because we might want longer bake times, or priorities may change enough that we refocus on other tasks first. That said, I can at least give some broad strokes about where we're heading.
Apr 28, 2014 at 6:03 PM
@nabog - once I got started, looks like it went a little faster than I had thought. The roadmap and ES6 status are both in-progress, but at least you can get a rough idea of what the current focus is.