You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
which with compiler --compilation_level ADVANCED --language_in ECMASCRIPT_NEXT --strict_mode_input --language_out ECMASCRIPT_2017 --assume_function_wrapper --use_types_for_optimization compiles to:
I'm not sure if this is ever incorrect, but this seems surprising? In this instance it's more characters, plus it's (slightly) increasing the work for the ultimate interpreter/compiler who'll now have to deduce that a is const rather than verifying it's const to perform optimisations. Admittedly that won't make a difference in this snippet but I noticed this in a hot loop in my code while profiling and trying to optimize.
The text was updated successfully, but these errors were encountered:
What's happening here is due to an optimization called variable coalescing.
Basically, the compiler realizes that it can have fewer variables (and, thus variable declaration statements) by using a single variable to do what was done with multiple variables in the original code.
The compiler recognized that a was unused after the while loop and i was never used before it, so it combined them into one variable, which also ended up having the name a. Since the value of the variable must change, it couldn't be const anymore.
Why did the compiler use var, instead of let? There are a few reasons.
The bulk of the compiler was written long before let and const existed. As a result a lot of the transformations it performs just always use var.
We also favor using the oldest-possible feature in many of our transformations, because it avoids us having to make all of the optimizations smart enough to pay attention to what language features are allowed in the output.
It would be pretty bad if we transpiled away all of the instances of let only to have a newly-written optimization end up putting one back in. Sure we could check the language output level in every place where we create a variable declaration, but that's adding even more logic that could potentially break.
We did recently have to fix a case where putting in var actually broke the code.
If you find one of those, please file a new issue.
const
variable declarations are sometimes demoted tovar
declarations. See for example:which with
compiler --compilation_level ADVANCED --language_in ECMASCRIPT_NEXT --strict_mode_input --language_out ECMASCRIPT_2017 --assume_function_wrapper --use_types_for_optimization
compiles to:I'm not sure if this is ever incorrect, but this seems surprising? In this instance it's more characters, plus it's (slightly) increasing the work for the ultimate interpreter/compiler who'll now have to deduce that
a
isconst
rather than verifying it'sconst
to perform optimisations. Admittedly that won't make a difference in this snippet but I noticed this in a hot loop in my code while profiling and trying to optimize.The text was updated successfully, but these errors were encountered: