Apparently the reason "node --harmony --use-strict" works is that v8 enters "extended mode" if both flags are used.
from: https://groups.google.com/d/topic/v8-dev/1vmieHKNihs/discussion "This CL introduces a third mode next to the non-strict (henceforth called 'classic mode') and 'strict mode' which is called 'extended mode' as in the current ES.next specification drafts. The extended mode is based on the 'strict mode' and adds new functionality to it. This means that most of the semantics of these two modes coincide. The 'extended mode' is entered instead of the 'strict mode' during parsing when using the 'strict mode' directive "use strict" and when the the harmony-scoping flag is active. This should be changed once it is fully specified how the 'extended mode' is entered." On Monday, December 31, 2012 9:18:05 AM UTC-6, Tristan Slominski wrote: > > You'll have better success with "node --harmony --use-strict". > > On Monday, December 31, 2012 8:58:37 AM UTC-6, Domenic Denicola wrote: >> >> On Sunday, December 30, 2012 4:40:19 PM UTC-5, Rick Waldron wrote: >> >>> >>> On Sunday, December 30, 2012, Tristan Slominski wrote: >>> >>>> RE: "No one should use --harmony today anyway.." >>>> >>>> I didn't see block-scoped "let" in es6-shim (pretty sure that's >>>> impossible to shim without compilation, right?), so although you make a >>>> good case for some things, availability of "let" and "WeakMap" is pretty >>>> compelling in --harmony. For the things it can address/shim, es6-shim >>>> looks >>>> like a good solution. >>> >>> >>> Ugh >>> Again, everything I said _still_ stands: the semantics of let are still >>> incomplete (temporal dead zone discussion) and there is a serious backward >>> compatible syntax issue yet to be resolved (let is not reserved and let >>> destructuring is ambiguous with dereferenced let identifiers). >>> >> >> +1. Additionally, `let` is not bound correctly in loop block heads with >> --harmony; in ES6 for (let x; ;) or for (let x in y) will create a fresh >> per-loop binding. This is a rather serious semantic change, so yet another >> reason for Rick's warning. >> >> Also, just tested this because I had a suspicion it might be the case: >> the semantics and syntax for `const` are quite borked, with no errors >> thrown on assignment and no syntax errors upon uninitialized const >> declarations (i.e. `const x;` instead of `const x = 10;`). >> > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
