<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 6, 2012, at 1:35 PM, Axel Rauschmayer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div>The issue is *how* the spec and implementations decide what is supported, and when to raise an error on new syntax mixed (after) old non-strict code (e.g., 'with').<br></div></blockquote></div><div><br></div><div>Ah, OK. I thought that one would be able to lump together ES5.non-strict and all prior ES versions on one hand and ES6 and ES5.strict on the other hand.</div></div></blockquote><div><br></div><div>Notice that two of the four states contain possible outcome</div><div><br></div><div><span class="Apple-style-span" style="font-family: monospace; ">terminate with Error: invalid combination of ES5 and ES6 features</span></div></div><div><br></div><div>These are the states labeled ES5 and ES6.</div><div><br></div><div>It should be clear that you need more than two states to judge whether a given hunk of code is ES5 non-strict (or lower) -- the default unversioned <script> JS we know today -- or ES5-strict or higher. To have only two states in the machine, you would need version-based opt-in.</div><div><br></div><div>But don't worry about counting states. Count minimal or even non-minimal "modes" if you like ;-).</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div> But it makes sense that even if developers (engine users) are presented with something simple, implementors have to take care of many more details.</div></div></blockquote></div><br><div>A point that I flog often. The few and skilled implementors should take some complexity on behalf of the whole user base, provided that complexity in implementation and specification saves the bulk of users enough by simplifying migration and adoption.</div><div><br></div><div>IMHO we are onto something good here. The complexity for the implementors does not too bad (I'm looking at it right now for SpiderMonkey), and the user-facing wins are huge.</div><div><br></div><div>/be</div></body></html>