Hacker News new | ask | show | jobs
by chrisseaton 2049 days ago
Right... but the question was 'why can't the same thing be done with let'.

The answer is probably a combination of 'they haven't gotten around to it yet', 'they don't see the need', 'they don't want the complexity', and 'they don't want to spend compile time doing that.'
2 comments
franciscop 2049 days ago
Because you cannot know whether the let variable is changing just with static analysis without running the associated code, right?
link
lenz2020 2049 days ago
In strict mode you can because you can statically determine if eval is present. If it isn't, it is trivial to determine if it is written to after initialization.

Otherwise it has the same issues as const (is there a temporal dead zone violation?)

link
chrisseaton 2049 days ago
> just with static analysis

You're not doing static analysis - you're doing dynamic analysis and speculation. But this has the downsides I said - it's more complicated, it takes more time, etc.

link
klodolph 2049 days ago
What speculation? If you have a "let" in some lexical scope, AND this is strict mode, AND there are no calls to eval in that scope, AND there are no assignments within that scope... how is that different from const?

I can understand why in a JavaScript engine there may be plenty of other concerns and it may be completely reasonable to not do the analysis, but in the common case it should (at least) be something you could do just by walking the AST, if you so desired, without even knowing the surrounding code.

link
chrisseaton 2049 days ago
> What speculation?

Speculating that a debugger is not attached and modifying local variables, is one example.

> in the common case it should (at least) be something you could do just by walking the AST

Yes that’s why it’s speculation - handle the common cases and speculate away the uncommon cases.

link
Dylan16807 2049 days ago
> Speculating that a debugger is not attached and modifying local variables, is one example.

A debugger can do anything. You can't outthink a debugger and shouldn't try.

> Yes that’s why it’s speculation - handle the common cases and speculate away the uncommon cases.

Speculation is when you guess and need to have a guard in case the guess is wrong. They're describing a situation where it can't be wrong and you wouldn't need to speculate.

link
chrisseaton 2049 days ago
> A debugger can do anything. You can't outthink a debugger

Yes that's what we're saying. So you deoptimise when someone starts debugging.

> and shouldn't try

You'd get extremely slow code with this approach!

> Speculation is when you guess and need to have a guard in case the guess is wrong.

Yes, you're guessing that nobody will attach a debugger and you're guarding that no debugger has been attached. That guard is usually implicit.

> They're describing a situation where it can't be wrong and you wouldn't need to speculate.

It can be wrong... if someone's using a debugger. So you need to speculate that they aren't using a debugger.

I wrote a PhD about using speculation and deoptimisation to solve the problem of people debugging optimised code.

link
ConcernedCoder 2049 days ago
The question needs to be "why on earth would you want to do that with let, when you should just make it a const?"
link
klodolph 2049 days ago
Because minifiers can shave a few bytes by converting a mixture of const/let to use just let.
link