1/ to be specific: let bindings are already protected from casual reassignment; "let x = 1; let x = 2" is an error.
3/ if you already had to choose to mutate the binding, what value did you get from *also* having to change const to let?
-
-
4/ as for static analysis or optimizations, compilers should be able to easily treat single-assignment lets as const; it's purely lexical
-
5/ with the exception of globals, which is not the situation I'm talking about (global consts seem fine)
-
@wycats okay, if global const seems fine then I don't think we have an issue. :) consts defined at the top of a file seems best practice -
@keithwhor cool. I was mostly reacting to a pattern of using const for all bindings in a program. -
@wycats@keithwhor I dunno, I can understand it. The whole point is to be able to use as close to equational reasoning as possible, right? -
@wycats@keithwhor with const-by-default you can find the decl, and know you aren't going to find any reassignments. -
@wycats@keithwhor at that point, "let" stands out as something that requires explanation
End of conversation
New conversation -
-
-
@wycats It also prevents a potential shadowing hazard if you remove a let binding that shadows a const, while missing the mutation. -
@sebmarkbage I don't get it. Can you show me the code? -
@wycats Take `const x = 1; ... { let x = 2; ... x = 3; }` then you make this refactor `const x = 1; ... { ... x = 3; }`. Minor safety.
End of conversation
New conversation -
-
-
@wycats val to me is not preventing reassignment but being clear to readers that this will continue to reference the same val throughoutThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.