Downlevel emit for let\const

[vladima]

• changes in tests related to computed properties are related to change createNode -> createSynthesizedNode in emitter.
• capturing block scoped variables in closures inside loops is not supported scenario in this PR though it can be added later

[JsonFreeman]

loop body, not loop initializer, right?

[jods4]

According to ES6 spec, let in the loop initializer is also scoped per iteration (so subject to the same downlevel codegen issues). Beware that browsers currently get it wrong (tested in IE11, FF33).

[JsonFreeman]

Yeah I learned that while in the middle of reviewing this PR. I still do not quite understand the difference between the loop scope and the body scope, given that they are both per iteration. I suppose the difference is that you can access the loop scoped bindings in the initializer, guard, and incrementor of the loop, but they will be shadowed as soon as the body starts for that iteration. Though I still don't see how there could be a difference for for...in and for...of.

[jods4]

To be honest I don't think that there is any useful difference between the two. But there is a technical difference, as the loop body is a new scope nested inside the loop scope itself. It means that you can redeclare let i both in the loop initializer and the loop body. The initializer, loop increment and loop condition share one scope, the loop body is a nested scope.

Allen makes it very clear in his answer to this question: https://esdiscuss.org/topic/in-es6-do-for-loops-with-a-let-const-initializer-create-a-separate-scope

[JsonFreeman]

Got it, thanks for explaining that!

[DanielRosenwasser]

I don't know what cleanLocals means without reading the function, and even then I don't know what the implications for this are. Can you leave a comment regarding the situations in which this is useful?

[JsonFreeman]

I don't understand this. Why is blockScopedContainer.locals populated? I thought it should always be empty to start.

[JsonFreeman]

👍

[basarat]

this will be a good better alternative to typeguards in my code:

var foo : Fancy|SuperFancy;
if(foo.superFancy){
  let superFancy : SuperFancy = foo;
}
else{
  let fancy : Fancy = foo;
}

[JsonFreeman]

@basarat, will that actually work? You can only dot into members that exist in all parts of the union.

[basarat]

@JsonFreeman if nothing else, you don't even need the union

var foo : any; // Note
if(foo.superFancy){
  let superFancy : SuperFancy = foo;
}
else{
  let fancy : Fancy = foo;
}

[JsonFreeman]

Yes, with any, that would work quite nicely.