<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 26, 2012, at 12:29 PM, Mark S. Miller wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Let's resolve this the same way as another open question left over from ES5: What about the built-in functions? These are neither strict nor non-strict, so ES5 is silent on whether they have these poisoned properties. This oversight has caused us tremendous pain in SES, as seen by searching for "caller" and "arguments" in <<a href="http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js">http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js</a>>. (93 and 50 hits respectively, most of which I believe are relevant.) At one point, browsers had ES5 conforming behavior that made them insecurable. Fortunately, the modern versions of all major browsers now have conforming and securable behavior, but this was achieved by side conversations outside the standards process. Now that it has been achieved without breaking the web, we are free to standardize a securable behavior.<br>
<div class="gmail_extra"><br></div><div class="gmail_extra">For built-in functions, I think the best answer is #2. Since built-ins are neither strict nor non-strict, #1 does not apply. #3-prime (defined below) is IMO inferior to #2 for catching bugs in old code, but the fact that modern browsers did not break the web perhaps indicates that we no longer need to worry about those bugs.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">For new function forms, which is best should be decided together with the built-ins. If the built-ins go with #2, the new function forms should probably go with #1, though #2 would be acceptable. If built-ins go with #3-prime, new function forms should probably also go with #3-prime.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">#3-prime is, of course, that we mandate that implementors not provide such insecurable magic. #3 as is is unacceptable, because the spec would be inadequate to reason about the security of a SES-for-ES6. If we can't agree on #3-prime, then let's agree not to do #3.</div></blockquote><div><br></div><div>thanks for bring up the built-ins. </div><div><br></div><div>For the new forms, I'd prefer #2, I believe that for ES5 we rationalized that we could place the poison pill restriction on strict function because such functions didn't exist in prior editions and hence introducing the poison pills on such new features could not introduce any (direct) compatibility issues for existing code.  The same logic would seem to apply to any new syntactic forms for functions that we add in ES6. From a compatibility perspective it should be safe to give them all poison pill properties.</div><div><br></div><div>Allen</div><div><br></div><blockquote type="cite"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 26, 2012 at 10:37 AM, Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">ES5 added "poison pill" properties to the strict mode function objects that were intended to prevent implementors from supporting the non-standard legacy "caller" and "arguments" properties on such objects.<br>

<br>
In ES6 we have several new syntactic forms for defining functions: arrow functions, concise methods, generators.  What should be do WRT the position pill properties for functions defined using such new syntax.  Possibilities:<br>

<br>
1)  Same as ES5 function definitions.  If strict they get the poison pills , if non-strict they don't.<br>
2)  All new function forms always get poison pills, even if they aren't strict.<br>
3)  They never get poison pills because new implementor would be silly enough to associate they legacy features with new syntax.<br>
<br>
Options 1&2 would essentially collapse to "always" if new function definition syntactic forms always produced strict mode code.  However, I believe, the current plan of record is that the new forms have the same strict mode opt-in rules as ES5 uses for function definitions.<br>

<span class=""><font color="#888888"><br>
Allen<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM<br>
</div>
</blockquote></div><br></body></html>