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

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

What are the type system implications?

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

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

👍

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.

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

My copy is at https://github.com/wagle/tagspace

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

Perry Wagle (@wagle)

I think Perry Wagle (@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 Perry Wagle (@wagle)'s case, perhaps JS2?) code.

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.

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

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.

Perry Wagle (@wagle)

Perry Wagle (@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.

change merged into master #904

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

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

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

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.

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.

Ryan Cavanaugh (@RyanCavanaugh)

I think a big part of what Ryan Cavanaugh (@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.

Daniel Rosenwasser (@DanielRosenwasser)

Daniel Rosenwasser (@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 ?

Navigation Menu

Repository navigation

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

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

RyanCavanaugh commented on Jul 28, 2014

electricessence commented on Aug 15, 2014

basarat commented on Aug 15, 2014

wagle commented on Oct 10, 2014

danquirk commented on Oct 10, 2014

wagle commented on Oct 10, 2014

wagle commented on Oct 10, 2014

duncanmak commented on Oct 10, 2014

danquirk commented on Oct 10, 2014

wagle commented on Oct 10, 2014

mhegazy commented on Oct 10, 2014

mhegazy commented on Oct 15, 2014

1 remaining item

mhegazy commented on Oct 25, 2014

binarez commented on Nov 29, 2014

mhegazy commented on Nov 29, 2014

fdecampredon commented on Feb 22, 2015

RyanCavanaugh commented on Feb 23, 2015

fdecampredon commented on Feb 23, 2015

DanielRosenwasser commented on Feb 23, 2015

fdecampredon commented on Feb 23, 2015

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions