<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jan 16, 2013, at 11:26 AM, Brandon Benvie <<a href="mailto:brandon@brandonbenvie.com">brandon@brandonbenvie.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">The incompatibilities between let/const as implemented in V8 and Spidermonkey and how they're specified in ES6 are an additional factor:<div><br></div><div style="">* Per iteration loop binding (V8 and Spidermonkey don't do this for let/const).</div></div></blockquote><div><br></div><div>let isn't really relevant in sloppy mode, unless we decide to take let over destructuring (which would make me really sad)</div><br><blockquote type="cite"><div dir="ltr">
<div style="">* TDZ. `x; const x = 10` works in V8 and Spidermonkey currently, specified to throw ReferenceError in ES6</div></div></blockquote><div><br></div><div>I'm not sure adding TDZ to sloppy mode is feasible for const.  OTOH const is such a clusterfoo in sloppy mode i'm not sure what the compatibility story is -- I haven't looked at the different behaviours sufficiently to see if they can be merged.  I suspect that they can be as const doesn't suffer quite as badly as block scoped functions.</div><div><br></div><div>Off the top of my head:</div><div>* JSC will rebind a const if it's in a const declaration, eg. const x = 5; log(x)/*5*/; const x = 6;log(x)/*6*/;  x = 7; log(x)/*6*/; </div><div>* Opera in the past used const as an alias to var, i don't know their current behaviour</div><div><br></div><div>I don't know which version of IE picked up const (i'm assuming 10 has it?)</div><div>and i'm not sure what V8/SM do.</div><div><br></div><div>--Oliver</div><br><blockquote type="cite"><div dir="ltr"><div style=""><br></div><div style="">I think there's other differences.</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Jan 16, 2013 at 2:00 PM, Oliver Hunt <span dir="ltr"><<a href="mailto:oliver@apple.com" target="_blank">oliver@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">let can't be used as an opt in (unfortunately :-( ) as it turns out let is used as a variable name in real world code.<div><br></div><div>Gavin and I briefly toyed with the concept of having let be a contextually identified, but that's not doable if you have destructuring assignment in sloppy mode.</div>
<div><br></div><div>My feeling is that destructuring assignment in sloppy mode is more of a win than let, although i'm not sure how others feel.</div><div><br></div><div>Note that this isn't a "opt-in", this is an attempt to try and minimise the differences between strict and sloppy modes.  My ideal is that anything that can be unambiguously supported in sloppy mode should be.</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>--Oliver</div></font></span><div><div class="h5"><br><div><div>On Jan 16, 2013, at 10:33 AM, Brandon Benvie <<a href="mailto:brandon@brandonbenvie.com" target="_blank">brandon@brandonbenvie.com</a>> wrote:</div>
<br><blockquote type="cite">Without using modules as the indicator, how do you know whether code is intended to be run as ES6 or not? Do let and const count as ES6 (retroactively applying to code using the old non-standard versions, which are still currently supported by V8 and Spidermonkey)? Does it apply to code that appears to use Map, WeakMap, and Set (though the code might well refer to shimmed versions of these and not otherwise expect to run as strict)?<div>

<br></div><div>While there are many things that will absolutely indicate intention to run as ES6, there's a number of examples of ambiguity that make me doubt how successful an absolute judgment can be. This is why I think giving modules a double use as implicit opt-in/pragma has merit.<span></span><br>

<br>On Wednesday, January 16, 2013, Andreas Rossberg  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1 January 2013 07:09, Mark Miller <<a>erights@gmail.com</a>> wrote:<br>


> On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich <<a>brendan@mozilla.com</a>> wrote:<br>
>><br>
>> Mark S. Miller wrote:<br>
>> I'm pretty happy with Kevin's compromise. Here it is again:<br>
>><br>
>> (1) No opt-in required for new syntax, except:<br>
>> (2) No breaking changes to sloppy mode, and<br>
>> (3) No grammar contortions (e.g. let) to support sloppy mode.  And<br>
>> (4) All new syntax forms with code bodies are implicit strict.<br>
>><br>
>> What do you say?<br>
><br>
> My preference order:<br>
><br>
> 1)<br>
> 1.a) To the extent clean and practical, new features are available only in<br>
> strict mode,<br>
> 1.b) Lexical f-i-b is available in sloppy mode as it is in ES6 strict, since<br>
> no browser will prohibit f-i-b syntax in sloppy mode. Better to have the<br>
> f-i-b sloppy semantics be aligned with the ES6 f-i-b strict semantics.<br>
> 1.c) modules (both inline and out) implicitly opt-in to strict mode.<br>
> 1.d) classes implicitly opt-in to strict mode.<br>
> 1.e) nothing else causes an implicit strict mode opt-in.<br>
><br>
> 2) Like #1 but without #1.d (which I think of as Andreas' position)<br>
<br>
Yes, although I'd even consider removing 1.c inline (matching your<br>
option 6 below).<br>
<br>
But what do you mean by "to the extent clean and practical"? In my<br>
humble opinion, only two options are really acceptable at all: either<br>
_all_ ES6 features work only in strict mode (my preference), or _all_<br>
ES6 features work in both modes (how I interpret 1JS). Something<br>
in-between, i.e., deciding inclusion into sloppy mode on a by-feature<br>
basis, is a non-starter in terms of usability and observable<br>
complexity. That is, rather (5) than (4) below.<br>
<br>
> 3) Like #1, but #1.e is replaced with<br>
> 3.e) All code bodies within new function syntax is implicitly strict.<br>
<br>
I'd be strongly opposed to this (and Kevin's point (4) in general).<br>
<br>
> 4) Like #3, but #1.a is replaced with<br>
> 4.a) To the extent clean and practical, new features are available in sloppy<br>
> mode.<br>
> I take it this is essentially your position and Kevin's compromise position?<br>
><br>
> 5) Where things stood at the end of the last TC39 meeting, where we were<br>
> violating the "clean" of #4.a to kludge things like "let",<br>
> non-duplicated-formals-sometimes, no-arguments-sometimes, weird scoping for<br>
> default argument expressions, etc, into sloppy mode.<br>
><br>
> 6) Like #2 but without #1.c. Is this essentially Kevin's pre-compromise<br>
> position?<br>
_______________________________________________<br>
es-discuss mailing list<br>
<a>es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
_______________________________________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div><br></div></div></div></blockquote></div><br></div>
</blockquote></div><br></body></html>