A few arrow function specification issues

Domenic Denicola domenic at domenicdenicola.com
Sat Apr 21 13:17:06 PDT 2012

> -----Original Message-----
> From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
> bounces at mozilla.org] On Behalf Of Angus Croll
> Sent: Saturday, April 21, 2012 16:03
> To: Allen Wirfs-Brock
> Cc: es-discuss
> Subject: Re: A few arrow function specification issues
> >>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.
> What is the pro of ignoring explicit |this| binding instructions in
> call/apply on arrow functions?
> What is the con of continuing to allow legacy code to speculatively bind
> the |this| value when invoking any function?
> Why is it so important that fat arrows do a hard |this| binding?

It's important, as someone who hands off an arrow function to another part of the system, to ensure that `this` means what it meant while I was originally writing the code. This guarantee is vital for predictability of behavior. Consider

let mapped = array.map((el) => el * this.x)

If I cannot guarantee a lexical `this`, I am back to programming with `let that = this`, which is part of what arrow functions are trying to avoid. The only alternative is reading the source code and/or spec for every system that I hand off an arrow function to, since I need to know if they will clobber the lexical `this` I was trying to program against.

Note that this isn't a security issue---I'm not worried about "malicious code" messing me up. I'm simply trying to juggle the minimum number of factors on my precious brainstack, and when I'm trying to get a mapped array, I really don't want to think about whether `map` is going to mess with my `this`.

More information about the es-discuss mailing list