On Sep 29, 2011, at 12:14 PM, Sean Eagan wrote:
> On Thu, Sep 29, 2011 at 1:31 PM, Allen Wirfs-Brock
> <[email protected]> wrote:
>>
>> ...
>
>> I haven't written the spec. for spread in argument lists but clearly
>> interior holes need to be passed as undefined. Trailing holes in a spread
>> in the final argument position could be trimmed but that would mean that:
>
> So you don't think holes should appear in rest parameters or
> `arguments` ? The only reason I can think of to require that is that
> old code may expect `arguments` not to contain holes, but then it
> could be spec'ed that holes only appear in rest parameters. Beyond
> that is seems like it would make sense to be consistent with array
> literal hole preservation.
No I don't. Currently there is no ways to syntactically generate an actual
argument list with holes and I think that allowing ,, in argument lists is not
particularly desirable. Also apply replaces holes with undefined so there is
currently no way to create an arguments object that initially contains holes
(somebody could delete elements after it was created). It seems highly
desirable that we preserve the existing semantics of arguments and that:
function foo(...args) {
assert(length.arguments === length.args};
for (let i in arguments) assert(arguments.hasOwnProperty(i) ===
args.hasOwnProperty(i) && arguments[i] === args[i]);
}
regardless of how foo was called. In other words, baz(...bar) and
baz.apply(undefined,bar) should always produce the same effect.
Also, note that I've currently spec'd ES6 so that 'arguments' can be used as a
rest parameter name. In other words
function foo(...args) {return args}
and
function foo(...arguments) {return arguments}
are semantically equivalent.
I did this to enable to make it easier to migrate code such as:
function foo() {baz(arguments)}
to
function foo(...arguments) {baz(arguments)}
allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
