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

Brendan Eich brendan at
Thu Sep 11 11:34:36 PDT 2008

On Sep 9, 2008, at 11:32 AM, Mark S. Miller wrote:

> On Tue, Sep 9, 2008 at 9:21 AM, Mark S. Miller <erights at>  
> wrote:
>> How to restrict 'arguments' in strict functions?
>>    anticipation of ES-H-strict -- prohibit co-existence with splat
>>    arguments.callee
>>    joining? frozen?
> If we were making the jump from ES3 directly to ES-Harmony, we would
> probably prohibit the magic 'arguments' object in ES-Harmony strict
> functions, since its functionality is better served by optional and
> rest parameters. However, ES3.1 won't have optional and rest
> parameters, so 'arguments' will remain as the only way to do var-args
> functions in ES3.1-strict code. Given that ES-H-strict is upwards
> compatible from ES3.1-strict, this prevents us from prohibiting
> 'arguments' in ES-H-strict.

And it might be an undue migration tax, but I agree based only on the  
argument you make.

> The most we can do (which we should do) is
> prohibit 'arguments' in strict ES-H functions which use optional and
> rest parameters. (This is upwards compatible, since these features are
> new.) However, ES-H-strict must still allow 'arguments' in other code.
> If strict 'arguments' is to be better behaved and upwards compatible,
> we must make the critical fixes in ES3.1-strict.

Probably so, but did you post on this topic yet:

> (In a
> separate note, I'll explain why we want the otherwise-unspecified
> Function.caller, Function.arguments, and arguments.caller to throw for
> strict functions.)

I snipped your words about callee, but it's used quite a bit in Ajax  
libraries, e.g, Prototype:

$ grep -w callee prottype.js
     replacement = arguments.callee.prepareReplacement(replacement);
     var self = arguments.callee;
     parts.add = arguments.callee.addPair;


In ES4 we proposed new syntax (that violate the holy Tennent) to get  
callee: |this function|. ES4 proposed to deprecate arguments by  
specifying only rest and optional parameters normatively, leaving  
arguments (which has never been fully specified to be web-compatible)  
to an informative annex.

With 3.1 and Harmony we may have to keep arguments "more normative"  
but reform it in strict mode till it's vestigial, while adding rest  
and optional params. Sounds like a plan. But arguments.callee use  
cases deserve a look. They are out there, in great number.

The TIBET guys would want a replacement for arguments.caller, but I  
would not miss it. But it's not in ES3 at all, right? Ban all such  
caller variations in strict mode, I say!

> Strict 'arguments' should not be joined to its function's parameters.
> In order to get better diagnostics for migrating old code to strict,
> should 'arguments' also be frozen?

That would catch assignments to arguments[i] for i < actual argument  
count, but it would not catch expectations that x = y in function f 
(x) {...; return arguments[0]} would return y.

> 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.
> Thanks.

I followed up to no reply -- did my post help?


More information about the Es-discuss mailing list