Allow pure ECMAScript block

[NN---]

Motivation:
TypeScript currently doesn't support all ES6 features and it takes time for supporting them.
Moreover each vendor plays with new ES extensions like ES7 draft and so on.

Proposal:
Allow pure ECMAScript block which is not treated as TypeScript.
It is pretty similar to '_asm' directive in C language.

This allows to use generators of ES6 while TS doesn't support them:

__ecmascript {
  function *foo() {
    yield 1;
  }
}

// Since the block is not parsed by the TS compiler we must declare the function.
declare extern foo() : any;
var it = foo();
var value = it.next();

Or 'const' which is not supported in TS 1.3:

__ecmascript {
  const A = 1;
}

// Declaring 'A' to be used in the code.
// TS compiler doesn't protect us from assigning to 'A' but ES engine does.
declare var A : number;

[NoelAbrahams]

What's wrong with just adding an ES6 compiler option? (e.g. #595)

[NN---]

There is nothing wrong with that but it takes time for implementing the full ES6 spec.
Also think about future, ES7 would have new features, perhaps new syntax.
This will allow to mix in one file TS and new ES syntax.
Currently I have to split my code into consts.js for 'const' syntax and myfile.ts for the rest.

[NoelAbrahams]

I believe that is the idea see #904. It's not about down-level emit.

[NN---]

As I said it is not only about const or ES6, it is about any future feature to be used natively in TS without adding additional ES files until TS supports it natively.

[saschanaz]

One may use async/await in that block and give the compiled result to other converter for ES6. 👍

[danquirk]

Curious what platforms you're targeting where you're using some of these features already given the sparse support I see so far (http://kangax.github.io/compat-table/es6/).

[jods4]

@danquirk: no need for platform support, you can transpile your code, e.g. using 6to5. Those features make your dev experience much better. BTW, IE12 is expected to come out early this year and have complete ES6 support. You can expect the other browsers to follow suit.

I think I opened #1641 for the same ground reason: TS is great but its lack of ES6 features is getting more and more frustrating :( For big new projects I'm torn between TS and ES6/7...

[basarat]

👍 e.g. the following

__ecmascript {
  function *foo() {
    yield 1;
  }
}

would emit the following and not do any type checking

  function *foo() {
    yield 1;
  }

It can be useful for the use cases already mentioned (i.e. using an alternative ES6 transpiler) plus also helps with bringing in JS codebases into a TypeScript file without seeing all the red lines.

[NoelAbrahams]

I fear this may leave the codebase open to abuse:

__ecmascript {

 // Can't be bothered to annotate
}

When compilation is permitted to have holes cut out, confidence in the system will be undermined.

[jods4]

I agree opening holes like that is denying a lot of benefits of having a complete Typescript codebase with "no implicit any" option activated. Good bye safe refactorings and find all references.

Moreover it's ugly and clearly a temporary hack until the language improves (but then you're stuck with it).

As much as I want TS to improve quickly towards ES6 compliance, this doesn't seem like a good idea to me.

[RyanCavanaugh]

ES6 features are coming online in the compiler pretty quickly (stay tuned). ES7 is supposedly going to have less new syntax than ES6 so I don't think this is going to be as much of an issue going forward. ES8, well, who knows, but we can see what that looks like when it gets closer.