A few arrow function specification issues

Alex Russell alex at dojotoolkit.org
Mon Apr 23 02:41:51 PDT 2012


On Apr 23, 2012, at 10:15 AM, Andreas Rossberg wrote:

> On 21 April 2012 01:22, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> Here are a few design alternates that have come up as I work the specification draft for arrow functions
>> 
>> 1) Always strict? Should all arrow functions be considered strict functions?
>> 
>> Pros
>> It's a new syntactic form, so it is it easy to make it be an implicit opt-in to strict mode.
>> We generally want to encourage use of strict mode.
>> 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)
>> 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.
> 
> One more: It makes the rules for what mode applies where more
> complicated and less obvious.

Unsurprisingly, I agree.

> To be honest, that suggestion confirms one of my fears about "1JS" --
> ending up with a more complicated language with ad-hoc rules about
> which mode applies in which context. Please let's try to resist the
> temptation. As much as I would like to encourage strict mode, I think
> we should keep it orthogonal to other constructs as much as possible.
> I can bear tying it to modules, but let's not go any further.
> 
> 
>> 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
> 
> Same here. If it's sloppy mode, let the sloppy mode rules apply as usual.
> 
> 
>> 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.
> 
> I suppose the most natural semantics would be that, like 'this', '
> arguments' is bound lexically from a surrounding function, if present.
> But that's perhaps too confusing, so I'd be fine with ruling out its
> use completely.

We might be able to do soft binding without much ambiguity. I'll post something here about it under separate cover.

>> 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.
> 
> Yes, that is consistent with what happens today when you call/apply a
> function after 'bind'.
> 
> 
>> 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.
>> 
>> I propose that arrow functions do not have a  [[HasInstance]] internal method.
> 
> Agreed. It would be weird to support HasInstance in the absence of the other.
> 
> 
>> 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.
> 
> For simplicity and uniformity, I'd keep the same semantics as for
> ordinary functions. Don't special-case if there is no strong reason to
> do so.
> 
> 
>> 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?
> 
> I'd prefer if concise method syntax stayed simple syntactic sugar for
> functions. Methods obviously need dynamic this. If you combine that
> with changes like the above, then you have implicitly introduced a
> third kind of function that cannot be described as (simple) syntactic
> sugar for any of the other two. That would be unfortunate, IMO.
> 
> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

--
Alex Russell
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723



More information about the es-discuss mailing list