[rewq4321]

JavaScript is very dynamic. Here I define a variable with `let` and then change it:

let foo = 10; eval("fo"+"o = 10");

I could "obfuscate" that eval assignment as much as I like. So you can't completely statically analyse `let` variables.

That said, it's likely you'd end up with perf very close to `const` in a very "hot" part of your code, since a good JIT compiler like V8 will eventually make "assumptions" about your code, and optimise around them, while having (ideally cheap) checks in place to ensure the assumptions continue to hold.

[jlokier]

An interesting point, however direct "eval" is a special case.

It's already known that functions containing direct "eval" are not subject to the same level of performance optimisations as other functions. There is no way to obscure the call to direct "eval" itself; the compiler knows clearly whether it occurs.

Without "eval" appearing syntactically inside a function's scope, there is no dynamic access to "let" variables, and there's no need for the JIT code to check the assumption at run time.

Despite no other assignments, the "let" variable does change value: It has the assigned value after the "let", and the "temporal dead zone" value before it in the same scope. However "const" also has this property so it's not obvious why there would be a speed difference.

[rewq4321]

> There is no way to obscure the call to direct "eval" itself; the compiler knows clearly whether it occurs.

I must be misunderstanding you, because you've stated that very confidently.

window["e"+"val"](...)

[syrrim]

> There is no way to obscure the call to direct "eval" itself;

Jsfuck would like to have a word with you

[jlokier]

Nice try! The Jsfuck method can't encode a direct "eval", only an indirect one :-)

Thus the emphasis on direct. Well, Jsfuck can encode a direct eval inside an indirect eval, but that doesn't give it any advantages, it still can't access the surrounding lexical environment in the form of "let" and "const" variables.

(I didn't know about Jsfuck though - it looks fun, thanks!)

[ithkuil]

Does it actually behave like having a literal eval in the function?

[Mavvie]

Doesn't JSFuck only work when strict mode is off?

[chrisseaton]

These checks can be completely free, in terms of runtime cost, through deoptimisation.

[gfxgirl]

How? You have to do some kind of check with let, and you don't with const.

[miloignis]

Not sure if V8 does this, but a general strategy used in HotSpot is to compile assuming the good case and install a "trap" to deoptimize the code if the condition is violated. So you could compile the let like a const with no checks on the use of the variable, but have a trap such that if any code ever tries to assign to that variable, all code compiled under the assumption that it was constant is throw out.