Allen Wirfs-Brock wrote:
1) Always strict? Should all arrow functions be considered strict functions?
Pros
P1. It's a new syntactic form, so it is it easy to make it be an implicit
opt-in to strict mode.
P2. We generally want to encourage use of strict mode.
P3. If not, there would no way to to make an expression-bodied arrow function a
strict function (other than by nesting it in strict code)
P4. Always strict eliminates the need for some of the arrow special case
alternatives discussed below
Cons
We shouldn't be trying to force use of strict mode.
Programmers who don't know about strict mode may get confused by the
application of strict mode semantics to arrow functions
It would create a refactoring hazard for non-strict code.
Pros outweigh Cons in my book, on their face. In particular the ones I
took the liberty of labeling P3 and P4.
I thought per 1JS that modules opt into strict mode (P1 but stronger).
P4 is enough by itself unless there's a big Con. I don't see one big
enough to matter.
2) Redeclaring eval in non-strict arrow functions
Should strict mode eval declaration/assignment restrictions be be imposed upon
non-strict arrow functions?
I propose disallow binding eval or assigning to it all arrow functions
Yes, and implied strict mode handles this.
3) Declaring arguments as a formal parameter, or local binding in a non-strict
arrow function
The wiki proposal says arguments can't be used as an expression primary but
doesn't say anything about declarations
I propose binding or assigning or referencing arguments within a arrow function.
With missing "to disallow", agreed.
4) Should it be a dynamic error to try to use apply/call to set the this
binding of an arrow function.
Cons
To much existing code speculatively binding the this value when invoking a
function.
I propose that call/apply simply ignore the this value when invoked on an arrow
function.
Agreed. That's in the wiki proposal, as revised.
5) Should arrow functions define the [[HasInstance]] internal method.
In other words should should:
obj instanceof () => {}
do?
If it doesn't have [[HasInstance]] then instanceof would throw a type error.
Alternatively, it could have a [[HasInstance]] that always returns false.
We have already decided that arrow functions don't have a [[Construct]]
internal method nor a prototype property.
Yes, so it follows no [[HasInstance]]. This is an oversight in the proposal.
I propose that arrow functions do not have a [[HasInstance]] internal method.
Agreed.
6) Do arrow functions need to have per instance "caller" and "arguments" poison
pill properties?
I propose no, because they are a new feature. But we can include a NOTE warning
against providing their non-standard legacy implementation.
NOTE sounds good, and we should not poison new ground.
7)All of the above questions also apply to functions defined using concise
method syntax in object literals or classes. Should the same answers apply to
them?
Question 4 does not -- methods must have dynamic |this| and you can
substitute another object via .apply/.call.
Otherwise I'd make them the same. I suspect there will be arguments to
support new and instanceof. Use a function-valued property if you need
to (my response).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
