Bait taken: Arguments about arguments

Mark S. Miller erights at
Wed Jan 14 21:16:35 PST 2009

On Wed, Jan 14, 2009 at 7:08 PM, Brendan Eich <brendan at> wrote:

> When in doubt, use brute force. ES3 already did. Quoting from its spec for
> Function.prototype.apply:
> * Function.prototype.apply (thisArg, argArray)*
> [...] Otherwise, if *argArray *is neither an array nor an arguments object
> (see section 10.1.8), a *TypeError *exception is thrown. If *argArray *is
> either an array or an arguments object, the function is passed the
> (ToUint32(*argArray*.length)) arguments *argArray*[0], *argArray*[1], …, *
> argArray*[ToUint32(*argArray*.length)–1]. [...]

Yes, this is the spec text I quoted as well. But I don't understand it or
your "use brute force" answer. How does Function.prototype.apply determine
that argArray is an arguments object? What semantic state distinguishes it
from any other array-like non-array object that inherits from
Array.prototype? If an implementation is necessarily required to associate
such extra semantic state in order to conform to the spec, shouldn't the
spec admit that

1) at least by introducing an internal property for that purpose? After all,
that's what the internal properties are for.

2) Alternatively, if its [[Class]] were "Arguments",
Function.prototype.apply could test whether the [[Class]] were "Array" or

3) Or we could take David-Sarah's suggestion and generalize
Function.prototype.apply to accept any array-like object as its second

We need to do something, since as it stands the operational spec is
unimplementable in terms of the specified semantic state.

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

More information about the Es-discuss mailing list