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

Suggestion: Support ES6 'let' and 'const' keyword #19

Closed
RyanCavanaugh opened this Issue Jul 15, 2014 · 21 comments

Comments

Projects
None yet
10 participants
@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Jul 15, 2014

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-let-and-const-declarations

The only major implication here how we would treat export const x = 4; in the context of an internal module, as this basically introduces the concept of a readonly variable. See #12

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

RyanCavanaugh commented Jul 28, 2014

What are the type system implications?

@electricessence

This comment has been minimized.

Copy link

electricessence commented Aug 15, 2014

I would state that there's two sides to this:

  1. The target language is JavaScript and without the use of ES5 accessors or something greater than ES5, you're not really getting any benefit here in the end code.
  2. const and readonly in C# do not behave the same from a compile stand point. const should exist statically or in an instance but must be initialized before the constructor can only be set by the definition. Where as readonly must be initialized before the constructor finishes.

Personally I like the idea of having const and readonly as an option. It may make things more complicated, but I like that it is explicitly declaring intent. Also, currently, it isn't possible to ensure an initialized value before the constructor is called.

@basarat

This comment has been minimized.

Copy link
Contributor

basarat commented Aug 15, 2014

👍

@wagle

This comment has been minimized.

Copy link

wagle commented Oct 10, 2014

I've inherited a very large firefox add-on, written largely in javascript, that uses const and let all over the place. I'm trying to use typescript to debug, annotate, and refactor this legacy code. It seems a shame to remove "const", and I'm currently unsure how to remove "let". What's the status of including these features? I'm confused by the move from codeplex to github, the threads seem to dissipate.

How can I help? I really need this add-on to work right.

@danquirk

This comment has been minimized.

Copy link
Member

danquirk commented Oct 10, 2014

Can you share what add on it is? We've been prioritizing ES6 features for which we can generate ES5 compatible code under the assumption that there's more value there until ES6 support is more prevalent in browsers (and thus more prevalent in JavaScript apps).

@wagle

This comment has been minimized.

Copy link

wagle commented Oct 10, 2014

@wagle

This comment has been minimized.

Copy link

wagle commented Oct 10, 2014

Apparently const and let have been in mozilla's internal javascript forever.

@duncanmak

This comment has been minimized.

Copy link

duncanmak commented Oct 10, 2014

I think @wagle brings up another good point.

Like I wrote in #595, IMHO it's a quicker path and possibly more immediately useful if there's an additional code-gen path to emit non-ES5 (i.e. ES6, or in @wagle's case, perhaps JS2?) code.

@danquirk

This comment has been minimized.

Copy link
Member

danquirk commented Oct 10, 2014

Newer browsers do tend to support let/const (http://kangax.github.io/compat-table/es6/) but as you can see it's by no means ubiquitous yet (ex iOS8 has no support for let, nor does IE10). We don't expect JavaScript developers en masse to take a dependency on those features until they're more common. Given that, we've been focusing our near term efforts on the ES6 features which we can give people the ability to leverage whether or not the browser supports them yet (ie can emit ES5 compatible code that models the ES6 semantics). That said, ES6 specific features like let/const are certainly important to us.

@wagle

This comment has been minimized.

Copy link

wagle commented Oct 10, 2014

Yeah, I guess I need something like "--target js2", and no-one seems anxious to implement the mozilla javascript target.

In theory, I'm capable of adding const and let to your transpiler (5 semesters of compilers, years ago), but I'm not yet a "Javascript language lawyer", so I'm uncomfortable. I'm desperate to get this plugin debugged and extended this fall, so it looks like I'm going to try adding these keywords.

Adding const seems moderately straightforward, just look for assignments in the scope.

I'm not entirely sure what exactly let does yet (give me a day or two), but it just seems to limit the scope of what might be a var even more (correct me if I'm wrong).

(1) Would you need me to translate these to ES5 (or all the targets), or can I just disallow it?

(2) I might find that my plugin uses more than const and let, so I'd need those to. Would you expect me to implement all of "js2"? Or do I fork because I didn't do it all?

(3) Oh. Is the intention for there to be only one source language (typescript), but multiple targets (dialects of javascript)?

@mhegazy

This comment has been minimized.

Copy link
Contributor

mhegazy commented Oct 10, 2014

The way we would approach this is adding a new ES6 target. let and const will only work in ES6 but disallowed in other targets. An example to follow would be get and set accessors under ES3.

TypeScript is intended to be a super set of JavaScript, so the first thing to do here would be to go through the ES6 spec for let and const (http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts).

Let and const provide block scoping, const adds an additional constraint of being readonly.

If there are other ES6-specific features that you need let's take them on a case-per-case basis.

let me know if you have other questions.

@mhegazy

This comment has been minimized.

Copy link
Contributor

mhegazy commented Oct 15, 2014

@wagle I have initial support for let and const,(https://github.com/Microsoft/TypeScript/tree/letAndConst) I am still missing some checks to disable emit if any of the let and const errors were encountered, but it should be usable. Give it a try and let me know how it fares.
The problem however is that browsers vary dramatically in their support for let and const. even ones that do support them do no necessary agree on the semantics. My implementation tries to follow the latest draft for ECMAScript6.

@wagle

This comment has been minimized.

Copy link

wagle commented Oct 19, 2014

Problem is that I’m using firefox’s javascript for extensions/add-ons.

I’ve slurped my add-on into webstorm, and it seems to turn out that it is unhappy with some of the original javascript. It will take me a couple days to make webstorm happy (I have a backlog of stuff to do), and then I will see what makes typescript+letAndConst unhappy.

Thanks!=

@mhegazy

This comment has been minimized.

Copy link
Contributor

mhegazy commented Oct 25, 2014

change merged into master #904

@binarez

This comment has been minimized.

Copy link

binarez commented Nov 29, 2014

Even if Typescript is a superset of ES6 and ES5, that doesn`t prevent it from checking assignments to a constant variable, does it? Even if it compiles to ES5 target, it can still check for this in TS and compile away the const when targetting ES5. Am I oversimplifying or what?

const and preprocessor defines (#ifdef DEBUG) seem to be simple features to add, I want them. I'm coming from C++ :)

@mhegazy

This comment has been minimized.

Copy link
Contributor

mhegazy commented Nov 29, 2014

This is something we are considering. There are problems imposed by the scoping of const and let; let and const are block scoped, meaning that in a loop every iteration has a fresh variable. You can not emulate this using var semantics, without introducing functions to create new scopes. While this is doable it can complicate the generated code and can have adverse perf impact. We have always tried to emit idiomatic JavaScript that would match a human-authored code.
Having said that, I think there is room for us to support let and const for ES5, through flagging captured variables in loops

@mhegazy mhegazy reopened this Nov 29, 2014

@mhegazy mhegazy closed this Nov 29, 2014

@fdecampredon

This comment has been minimized.

Copy link

fdecampredon commented Feb 22, 2015

This is something we are considering. There are problems imposed by the scoping of const and let; let and const are block scoped, meaning that in a loop every iteration has a fresh variable. You can not emulate this using var semantics, without introducing functions to create new scopes.

The case where you actually need a function to create a new scopes are pretty rare, could we not just error on those case ? I find it pretty domageable to not having let/const just for few cases.
see: https://github.com/olov/defs/blob/master/loop-closures.md

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

RyanCavanaugh commented Feb 23, 2015

The case where you actually need a function to create a new scopes are pretty rare

I'm somewhat surprised by this statement and would like to see some data either way (in terms of use of let "in the wild"). My impression is that using let in a loop construct to avoid explicit closures is arguably the single most valuable thing let actually does, but I could be wrong. The other cases are nice to have IMO, but loop closures are incredibly convenient.

@fdecampredon

This comment has been minimized.

Copy link

fdecampredon commented Feb 23, 2015

I'm somewhat surprised by this statement and would like to see some data either way (in terms of use of let "in the wild"). My impression is that using let in a loop construct to avoid explicit closures is arguably the single most valuable thing let actually does, but I could be wrong. The other cases are nice to have IMO, but loop closures are incredibly convenient.

From what I understand the only case where you need to emit a closure is when you capture the declared variable in something like a closure:

var arr= []
for (let i = 0; i < 10; i ++) {
  arr.push(() => i)
}

Any other case can be solved with variable renaming and compiler check, sure it's an handy case, but there is a lot of other case that are valuable and not being able to take advantage of this feature just for this case seems unfortunate.
Especially const is quite useful, and not only for scopes properties.

@DanielRosenwasser

This comment has been minimized.

Copy link
Member

DanielRosenwasser commented Feb 23, 2015

I think a big part of what @RyanCavanaugh meant is that let actually gives you the "intuitive" semantics for these cases, which is why it was ever desirable in the first place.

@fdecampredon

This comment has been minimized.

Copy link

fdecampredon commented Feb 23, 2015

@DanielRosenwasser While I agree, I still would like to see all other features being transpiled to es5/3, maybe should I create a new issue ?

@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.