Bait taken: Arguments about arguments

Mark S. Miller erights at
Wed Jan 14 14:54:57 PST 2009

On Fri, Jan 9, 2009 at 2:05 PM, Brendan Eich <brendan at> wrote:

> On Jan 9, 2009, at 1:58 PM, Brendan Eich wrote:
>  Probably much current aliasing is more of a source of buggy behavior than
>>> a feature used intentionally.
>> Another guess/assertion, but browser vendors cannot compete without
>> supporting aliasing. This suggests (but of course doesn't prove) that "use
>> strict" should not ban it.
> I really mean this: strict mode should ban things we know cause bugs, where
> we can cite the bugs. Not just corner cases you or I find unaesthetic.
> There's an element of "good taste" to strict mode's design, for sure, but it
> is not the only consideration. We went around the block on this point with
> respect to 'with', and I gave in.
> Parameter aliasing is not a source of bugs in my experience. Even 'with' is
> not, compared to undefined properties being typo'd. I'm concerned about
> disproportionate means being used (with opportunity costs) by those of us
> working on the language, as well as with making strict mode unusable on
> legacy code without too high a tax. I hope my turd-polishing language
> doesn't offend, but it would be a shame if we lingered over arguments at the
> expense of rest and spread.

No offense taken. And your points about opportunity costs are well taken.
I'd certainly like to stop spending time arguing about arguments, in order
to pay more attention to dozens of other more important things.

So let's imagine that we do nothing to "fix" arguments. How does magic
unfixed arguments play with the rest of the spec? Some questions:

1) Where is the semantic state that distinguishes magic arguments from other
array-like non-arrays that inherit from Array.prototype? There needs to be
such semantic state, to account for the acceptability of arguments as the
second argument of Function.prototype.apply, to whit:

(From of 22dec08 draft)
> Otherwise, if argArray is neither an array nor an arguments object (see
> a TypeError exception is thrown. If argArray is either an array or an
> object, [...]

Btw, that reference to 10.3.2 above looks like it should reference 10.5
Arguments Object, which says

> The arguments object is created by calling the abstract operation
> CreateArgumentsObject with arguments [...]

There is no separate definition of CreateArgumentsObject. Rather, it seems
its definition is the remaining text in 10.5. The spec here for non-strict
arguments gives it a [[Class]] of "Object" and a [[Prototype]] of the
original Array.prototype. It also, mysteriously, gives in a [[Constructor]]
of the Object constructor. But there is no internal [[Constructor]]

So, leaving aside the probably mistaken [[Constructor]] property,
Function.prototype.apply has no semantic state to inspect in order to carry
out its spec.

2) What happens when you freeze an arguments object?

In the Kona draft (and still in the 22dec08 draft), the joining of
non-strict arguments with the parameter variables is specified by
synthesizing getter/setter functions. At the Kona meeting, Waldemar (I
think) pointed out 1) that the way this was specified had inadvertent
non-hygienic lexical variable capture problems, and 2) given the new
attribute revelation APIs, such explanatory getters and setters could be
reified, requiring us to specify whether they're frozen, when they're ===,
etc. Rather than fixing these issues, at Kona we decided instead not to
specify them in terms of getters and setters. But then, what does
Object.getOwnPropertyDescriptor(arguments, '3') return? If it claims
arguments[3] is a writable data property, then one should be able to freeze
it. Once frozen, does this prevent writing the corresponding parameter
variable? Or does it sever the joining of arguments[3] and that parameter
variable? If instead it is specified with a non-configurable getter/setter
pair, then freezing does not affect it.

3) What happens when you write to an object that inherits from an arguments

    var sub = Object.create(arguments);
    sub[3] = foo;

does this assignment modify the parameter variable joined to arguments[3]?
Once again, if we think of arguments[3] as a data property, then the answer
should be no. We've instead created a new own '3' property on sub and have
not affected its parent. But if we think of it as an accessor property, then
this assignment should invoke the inherited setter.

Whatever we do with strict arguments, we need to answer all three of these
questions for non-strict arguments anyway. Until we settle the semantics of
non-strict arguments, it's premature to try to determine whether strict
arguments can live with that semantics.

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

More information about the Es-discuss mailing list