Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

Brendan Eich brendan at
Tue Sep 9 14:12:35 PDT 2008

On Sep 9, 2008, at 1:49 PM, Garrett Smith wrote:

> On Tue, Sep 9, 2008 at 11:32 AM, Mark S. Miller  
> <erights at> wrote:
>> Should strict 'arguments' be an array? I know we've over this before
>> and that strong reasons were presented why we couldn't do this.  
>> But on
>> the ES3.1 phone call this morning no one could remember or regenerate
>> those reasons. Anyone? Pointers to previous threads are a fine  
>> answer.

There was a narrow-cast thread among ES3.1 principals, I replied  
without enlarging it. Here's my last message in full, citing Allen's  

> I only now noticed that this mail spun off from a narrowcast mail  
> from Pratap, but the topic (arguments' type) deserves a wider list.  
> es3.x-discuss at is fine. May be that we are done with  
> this thread, but if not (or if it comes back to life), it should  
> not be too narrowly distributed. There's always the TC39 reflector  
> for member-only stuff.
> /be
> On Aug 1, 2008, at 6:26 PM, Allen Wirfs-Brock wrote:
> OK, I generally buy this, that arguments is an Object but its  
> [[prototype]] is Array.prototype. What about the semantics of its  
> length property and other array specific semantics defined in Array  
> instances’ custom [[Put]] method ([[ThrowablePut]] in the ES3.1  
> spec.). I would think--yes, which means we will need to define a  
> custom [[ThrowablePut]] for argument objects.  That is probably  
> also the appropriate place for defining the mapping to/from actual  
> parameters semantics.
> At least one thing in Array.prototype that doesn’t fit if arguments  
> is an Object and not an Array.  That is the definition of  
> constructor in Array.prototype. We can fix that by explicitly  
> providing an over-riding constructor property on arguments  
> instances.  Are there any other properties of Array.prototype that  
> need special consideration?
> Finally, this  brings to mind a subtlety to think about.  The  
> Object meta functions can expose whether or not a property is an  
> own property or an inherited property.  When the speciation says  
> (as it does in several places) that an instance of  a specific  
> constructor has certain properties are  we implying that those  
> properties must be observably own properties of the instance?  From  
> an implementation flexibility perspective I’d prefer that this was  
> left unspecified but from an interoperability perspective I suppose  
> we should pin it down.
> From: Brendan Eich [mailto:brendan at]
> Sent: Tuesday, July 29, 2008 7:34 AM
> To: Pratap Lakshman (VJ#SDK)
> Cc: crock at; Mark S. Miller; Kris Zyp; Mike Cowlishaw;  
> Adam Peller; Sam Ruby; Lars Hansen; ggaren at; Allen Wirfs- 
> Brock; Waldemar Horwat
> Subject: Re: ES3.1 WG phone conference 29 July 08:00 PT
> On Jul 29, 2008, at 7:04 AM, Pratap Lakshman (VJ#SDK) wrote:
> (3) arguments. I think we should make arguments a true ES array. We  
> should correct the specification error that allowed it to be  
> anything else.
> This is not possible without extra magic, due to the aliasing of  
> arguments[0] and x in
> function f(x){arguments[0] = 42; return x}
> It goes both ways of course:
> function f(x){x = 42; return arguments[0]}
> You can't require analysis to find the mutation (of either alias),  
> due to eval. We shouldn't require any kind of analysis in ES3.1 to  
> handle this aliasing. It has to be done as it has always been done,  
> by a magic arguments object whose element getters know how to find  
> the actual parameters, and whose element setters update those  
> actuals that correspond to declared formal parameters.
> Note that the last sentence requires the first call to f below to  
> return undefined, not 42:
> js> function f(a,b){arguments[1]=42;return b}
> js> f(1)
> js> f(1,2)
> 42
> For these reasons, arguments cannot be a true array. Such a change  
> is also not backward compatible in ways I recall Lars found out  
> about when he was at Opera.
> The only harmonized solution is to make arguments' prototype be  
> Array.prototype. Let's please do that, or else leave arguments alone.
> (4) Edits based on review feedback from Oslo; schedule for  
> circulating the next draft
> Sorry if I cannot attend this meeting -- I will try if my schedule  
> permits. I'm still traveling and I haven't had a chance to dig into  
> chapter 15 of the spec. I hope the above is clear.
> /be

Back to the present:

>> Thanks.

There are other threads covering arguments, not hard to find with or (although both have odd gaps in  
message indexing -- I'll talk to admins).

> The arguments object could have the same methods as array, like a
> "subclass" of array, but not have the special [[Put]], and concat()
> could still work the way it does with today's arguments object (I
> don't actually prefer the current behavior)

The plan has been to make arguments objects delegate to Array.prototype.


-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Es-discuss mailing list