The implementation of rest parameters in SpiderMonkey explicitly forbids a reference to the "arguments" binding within the body of a function literal with a rest parameter. As such, the script `function fn(a, b, ...rest) { arguments; }` yields a SyntaxError.
I am not seeing where this is supported by the specification, as I mention in https://bugzilla.mozilla.org/show_bug.cgi?id=574132.
I would like the appropriate behaviour to be clarified so that the SpiderMonkey implementation can be made spec-compliant (either by fixing the spec, or fixing SM), and so that a spec-correct version can be implemented in V8.
I am not positive if treating this as a static error is necessarily the best approach to take, but if that is the intent then it should be spelled out explicitly.
This is not strictly a technical issue, but an inconsistency between implementation reality and the text of the draft, which may require new language for incorporating the behaviour of the implementation, or otherwise strengthening the position of the current draft.
(In reply to Caitlin Potter (:caitp) from comment #0)
> The implementation of rest parameters in SpiderMonkey explicitly forbids a
> reference to the "arguments" binding within the body of a function literal
> with a rest parameter. As such, the script `function fn(a, b, ...rest) {
> arguments; }` yields a SyntaxError.
That's not correct according the current ES6 drafts. See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-functiondeclarationinstantiation which defines exactly when a 'arguments' binding is created.
>
> I am not seeing where this is supported by the specification, as I mention
> in https://bugzilla.mozilla.org/show_bug.cgi?id=574132.
>
> I would like the appropriate behaviour to be clarified so that the
> SpiderMonkey implementation can be made spec-compliant (either by fixing the
> spec, or fixing SM), and so that a spec-correct version can be implemented
> in V8.
>
Do you see anything unclear about the specification text referenced above? I believe it accurately reflects TC39's intended semantics.
> I am not positive if treating this as a static error is necessarily the best
> approach to take, but if that is the intent then it should be spelled out
> explicitly.
It's not supposed to be an error.
>
> This is not strictly a technical issue, but an inconsistency between
> implementation reality and the text of the draft, which may require new
> language for incorporating the behaviour of the implementation, or otherwise
> strengthening the position of the current draft.
The spec has evolves over various drafts and early implementations need to follow the revisions and be prepared to update them has the spec. evolved. Function declaration instantiation, in particular, has changed several times but is now quite stable. All implementations should review their conformance to the current specification.
Thanks for the clarification of intent. I was thinking it might not hurt to add another "**NOTE: Rest parameters do not preclude Arguments objects" somewhere in this case, just to help explicitly state this.
I appreciate that this should not be a static error, because it seems easier to implement this way.