14.3.1 Static Semantics: Early Errors:
The early error restriction for non-simple parameter lists should be possibly removed for consistency with "14.1.2 Static Semantics: Early Errors".
fixed in rev24 editor's draft
fixed in rev24
Per https://crrev.com/924403002/ it seems like maybe we don't want this early error to be removed.
It would be nice if the rules about "strict/new feature" vs "not-strict" parameter list static errors were a bit more consistent.
Is it too late to add it back?
What TC39 wanted to do here is minimize "micro-modes" which are restrictions that only apply to specific new features, particularly in sloppy mode.
'arguments', 'eval', and strict reserved word declaration restrictions are now imposed via the early error rules for BindingIdentifier and are only conditional upon strict/sloppy mode (but of course, all class definitions and and modules are always strict mode code). Simple/complex parameter list syntax doesn't have anything to do with those naming restriction issues anymore.
Duplicate parameter name are illegal in all strict mode code plus in all "complex" (ie, no new syntax present) parameter lists in sloppy mode.
The only semantics associated with StrictFormalParameters is that duplicate parameter names are also illegal for them in sloppy mode simple parameter lists.
So, arguably the only "micro mode" is duplicate parameter name restrictions in sloppy mode arrow functions, generators, and object literal concise methods and that doesn't seem so bad from a complexity perspective.
I'm not sure what your issue is with:
function f(...arguments) {
return arguments;
}
sloppy mode has always permitted using 'arguments' as a parameter name and doing that has always made the arguments object inaccessible. Just like ...arguments does.
I don't have a huge opinion on this, but implementation-wise, it's simpler for V8 if we can just bundle all of the "strict-ish" static formal parameter errors together. I think it's also less confusing if you don't have different subsets of strict errors conditionally applied to sloppy-mode. It would be simpler if non-simple parameter lists suffered all of the same early errors as simple parameter lists in strict code.
It would be simpler to only have 2 "modes". If SimpleParameterList is false then apply the exact same rules as for strict function formal parameters.
Allen, the "micro mode" conversation we had was about making the whole function (inlcuding the body) strict if the parameters were complex. We all agreed that that would not be good.
Still, this is such an edge case that I don't think end users ever have to care and the code paths in an implementation is manageable so I'll let this one slide. There are so many quirks already that one more will hardly be noticable.
(In reply to Erik Arvidsson from comment #6)
> It would be simpler to only have 2 "modes". If SimpleParameterList is false
> then apply the exact same rules as for strict function formal parameters.
>
Of course, simplicity is in the eye of the beholder so let me retry the explanation.
Whether "eval" and "arguments" can be used as a BindingIdentifier is solely determined by strict/sloppy mode. There is nothing about it that is specific to parameter lists.
"complex parameter lists" are new to ES6. They never allow duplicate definition of a BindingIdentifier and never produce a mapped arguments object. Again, this is a characteristic of the complex parameter list feature, and not affected by the mode.
"simple parameter lists" are a legacy feature and have strict mode restrictions (no duplicates, no mapped arguments object) that were defined in ES5. Those strict mode restriction continue to apply to them in ES6 and are solely determined by strict/sloppy mode.
There is an overlap between the strict mode simple parameter list restrictions and the (any mode) complex parameter list restrictions and recognizing this might be used to simplify (or perhaps complexify) an implementation. However, I think the overall story is simpler if we never talk about strict parameter lists as something that can exist in sloppy mode code.
(In reply to Allen Wirfs-Brock from comment #4)
> So, arguably the only "micro mode" is duplicate parameter name restrictions
> in sloppy mode arrow functions, generators, and object literal concise
> methods and that doesn't seem so bad from a complexity perspective.
>
I slightly misspoke above. "generators" should not have been mentioned as the restrictions only apply to generator concise method.