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:

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.

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:
https://typescript.codeplex.com/SourceControl/network/forks/kayahr/typescript/contribution/6570 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.

__extends

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

Symbols

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.

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):

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.