Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow pure ECMAScript block #1644

Closed
NN--- opened this issue Jan 12, 2015 · 20 comments
Closed

Allow pure ECMAScript block #1644

NN--- opened this issue Jan 12, 2015 · 20 comments
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript

Comments

@NN---
Copy link

NN--- commented Jan 12, 2015

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
Copy link

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

@NN---
Copy link
Author

NN--- commented Jan 12, 2015

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
Copy link

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

@NN---
Copy link
Author

NN--- commented Jan 12, 2015

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
Copy link
Contributor

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

@danquirk
Copy link
Member

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
Copy link

jods4 commented Jan 12, 2015

@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
Copy link
Contributor

basarat commented Jan 13, 2015

👍 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
Copy link

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
Copy link

jods4 commented Jan 13, 2015

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 RyanCavanaugh added Suggestion An idea for TypeScript Out of Scope This idea sits outside of the TypeScript language design constraints labels Jan 13, 2015
@RyanCavanaugh
Copy link
Member

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.

@jods4
Copy link

jods4 commented Jan 13, 2015

ES6 features are coming online in the compiler pretty quickly (stay tuned)

This is awesome news! Thanks.

@danquirk
Copy link
Member

@NN---
Copy link
Author

NN--- commented Jan 15, 2015

We are waiting.
The most needed feature for me are 'const' and 'let' .

@danquirk
Copy link
Member

let and const were added in October #904

@NN---
Copy link
Author

NN--- commented Jan 16, 2015

But still not in the official installer and VS integration :)

@danquirk
Copy link
Member

1.4 was released today and it's definitely in there.

@mhegazy
Copy link
Contributor

mhegazy commented Jan 16, 2015

@NN--- you would need to add lib.es6.d.ts explicitly to your project, see #1696 for details.

@NN---
Copy link
Author

NN--- commented Jan 17, 2015

@danquirk That's great !
There are no const enums for strings still, right ?

@DanielRosenwasser
Copy link
Member

@NN--- that's correct.

@microsoft microsoft locked and limited conversation to collaborators Jun 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

9 participants