On Tue, Jan 3, 2012 at 4:08 PM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jan 3, 2012, at 1:24 PM, Mark S. Miller wrote:<br>
<br>
>                            Just Two Modes<br>
<br>
V8 folks the other year had a catchier version: "no more modes".<br></blockquote><div><br></div><div>I am happy with that ;).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
<br>
> * ES6 non-strict mode must be practically upwards compatible from ES5 non-strict mode.<br>
<br>
</div>This is the part that's not clearly agreed to, or perhaps not even clearly proposed yet.<br>
<br>
Dave alluded to how we can decide on a case-by-case basis how new syntax using already-reserved (since ES1) keywords could be meaningful in <script> (no version) if the engine supports ES6 (or ES7, later, etc.).<br>

<br>
For example, class. </blockquote><div><br></div><div>A good example. Since the class proposal uses <span style> "</span><span style>private, public, static", by these principles, it would only be recognized in strict mode. If it appears in non-strict code, it would be a SyntaxError. </span></div>
<div><br></div><div><div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
*If* we support class in ES6, why shouldn't it be usable at top level not in a module (via module{...} or |use module;|)? The syntax is a guaranteed error in downrev engines.<br></blockquote><div><br></div></div><div>
It would be, so long as that code is strict. Just say "use strict"; outside a module and you can use classes.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Same for destructuring, rest/spread, etc. as I've mentioned in recent messages.<br></blockquote><div><br></div><div>"let" would only be allowed in strict code. ES5 non-strict allows "let" to be used as a variable name, so ES6 non-strict should too.</div>
<div><br></div><div>Want to use "let" scoping outside a module? Again, just say "use strict";.</div><div><br></div><div>What remaining issues are there in using destructuring, spread, or rest in non-strict code? The short answer, not knowing what conflicts you have identified, is that if it is painless and backward-compatible (see below) to accept these in both strict and non-strict, then we should. Otherwise, we accept these only in strict code.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Why you write "upwards compatible" you may mean something other than what's defined at<br>
<br>
<a href="http://en.wikipedia.org/wiki/Forward_compatibility" target="_blank">http://en.wikipedia.org/wiki/Forward_compatibility</a><br>
<br>
viz, new code degrades gracefully on old engines. If you mean that old code runs in new engines without changed semantics, that is downward or backward compatibility. I'm not sure what you meant so I'll stop here.</blockquote>
<div><br></div><div>I mean that "old code runs in new engines without [practically] changed semantics". Sorry for the confusion.</div><div><br></div><div>I insert [practically] above to cover cases like completion reform. Although it is not formally backward compat, if it doesn't break any real programs besides test262 tests, we should go for it and arrange to forgive ES5 engines that implement it.</div>
</div><div><br></div>-- <br>    Cheers,<br>    --MarkM<br>