new function syntax and poison pill methods

Mark S. Miller erights at
Fri Oct 26 12:29:18 PDT 2012

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.

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

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

More information about the es-discuss mailing list