new function syntax and poison pill methods

Mark S. Miller erights at
Fri Oct 26 13:06:36 PDT 2012

That makes sense. As I said, I'd be happy with #2 for both. But please
let's decide both questions together.

On Fri, Oct 26, 2012 at 12:46 PM, Allen Wirfs-Brock
<allen at>wrote:

> On Oct 26, 2012, at 12:29 PM, Mark S. Miller wrote:
> 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 <
> (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.
> 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.
> 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.
> #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.
> thanks for bring up the built-ins.
> 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.
> Allen
> On Fri, Oct 26, 2012 at 10:37 AM, Allen Wirfs-Brock <allen at
> > wrote:
>> 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.
>> 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:
>> 1)  Same as ES5 function definitions.  If strict they get the poison
>> pills , if non-strict they don't.
>> 2)  All new function forms always get poison pills, even if they aren't
>> strict.
>> 3)  They never get poison pills because new implementor would be silly
>> enough to associate they legacy features with new syntax.
>> 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.
>> Allen
> --
>     Cheers,
>     --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list