5 ms·

const IS valuable and necessary. 1) It means that every place the const appears it can be replaced with the const's value. Type checking can be streamlined, le

• titzer 11y ago
  1.) is simply wrong. Const variables have a live-range hole where access to the variable either throws or returns undefined, depending on the language mode (and the VM!). In either case it not legal to just smash in the constant. 2.) That's nice but JS semantics do not actually hold up. The intent is for a constant, the reality is there is a small window where the wrong results can be observed. Engines don't actually do any more optimizations than for var or let; in fact, your code may actually be slower due to the live-range hole checks.
  • pm24601 11y ago
    So you are saying that there are race conditions currently? Are any of this race conditions actually required by the language spec? If not, I suspect that those race conditions will be eliminated.
    • david-given 11y ago
      I believe that what the parent meant was that this: function f() { console.log(a); const a = 1; console.log(a); } ...actually returns this: undefined 1 So you get partially compile-time semantics (you can't assign to a) but partially run-time semantics (a only gets its value when initialised). Simply propagating the value of a's initialiser to all places where the variable is used is wrong, as this behaviour's required by the spec.
      • AgentME 11y ago
        Actually that code example should throw an exception when the first `a` is evaluated.
        • nullz 11y ago
          It doesn't in v8 -- what do you mean by `should`?
          • egeozcan 11y ago
            It's an implementation error. In Firefox, it correctly throws: > ReferenceError: can't access lexical declaration `a' before initialization
            • titzer 11y ago
              No, legacy const is not spec'd by ES5. It behaves differently in FireFox and V8 because it was added at different times with different semantics in the live range hole case. In strict mode, it will throw on V8 as well.
        • Skinney 11y ago
          No it shouldn't. `a` at the first console.log invocation IS undefined, so it is entirely correct.
          • anamexis 11y ago
            Not according to the spec[1]: > The variables are created when their containing Lexical Environment is instantiated but may not be accessed in any way until the variable’s LexicalBinding is evaluated. I.e. given a variable declared with `const`, you may not access it before it is set. [1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-let-and-const-declarations http://people.mozilla.org/~jorendorff/es6-draft.html#sec-let...
  • rescendent 11y ago
    Consts have other purposes: Speeding up global constants using fixed field optimization https://blogs.windows.com/msedgedev/2015/05/20/delivering-fast-javascript-performance-in-microsoft-edge/ https://blogs.windows.com/msedgedev/2015/05/20/delivering-fa...
• braythwayt 11y ago
  > 3) const + deep Object.freeze() makes for a complete const. The trouble with this approach is that runtime checks are only a guarantee that the code you've _exercised_ does not break the contract. In that respect, `const` is deeply different than `.freeze`, in the same way that runtime assertions are deeply different than type checking.
  • pm24601 11y ago
    Huh? That's why I pointed out the joint usage. And either way, a instant failure is better than a silent change.
• catshirt 11y ago
  isn't 2 kind of a misdirected optimization for an untyped language?
  • pm24601 11y ago
    How is INTENT of immutability ( and with const - now an enforced immutability ) misdirected optimization in any language. Javascript is dynamically weakly typed but it is still typed, typeof/instanceof exist for a reason.
    • catshirt 11y ago
      sorry right- weakly typed. my point is if you are using a weakly typed language, it doesn't care much about developer intent with respect to type. so why would it be concerned with developer intent with respect to mutability? seems arbitrary.
      • pm24601 11y ago
        maybe because developers in general prefer to not have bugs?
• jonny_eh 11y ago
  Aren't points 1 and 2 just arguments for a stricly typed language?
  • pm24601 11y ago
    Not at all. Simple things like instanceof / typeof checks can be resolved without a static type system. Because with a const everything is known about the const in question. Obviously the const prototype may change but then again if the const has a frozen prototype - that too can have static analysis applied to it. I am simply repeating the well-known benefits to immutables which is completely orthogonal to a type system, static or otherwise.
    • Havvy 11y ago
      instanceof cannot be determined statically because I can do... const a = {}; Object.setPrototypeOf(a, SomethingElse);
      • pm24601 11y ago
        really? even on a frozen object? Remember I have said const PLUS Object.freeze() Both are needed to get the true immutable effect.