# The other "this" for arrow function

**URL:** <https://es.discourse.group/t/the-other-this-for-arrow-function/1885>\
**Category:** 💡 Ideas\
**Tags:** proposal\
**Created:** [December 31, 2023, 9:51pm UTC](https://es.discourse.group/t/the-other-this-for-arrow-function/1885 "2023-12-31T21:51:02Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![kasper](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@kasper](https://es.discourse.group/u/kasper)\
**Post date:** [December 31, 2023, 9:51pm UTC](https://es.discourse.group/t/the-other-this-for-arrow-function/1885/1 "2023-12-31T21:51:02Z")

</div>

the point of introducing arrow functions was to provide a nifty and less chatty syntax for functions. it is adapted by masses. yet, there is one case which language doesn't allow.

today, this works

```javascript
String.prototype.test = function (v1, v2) { return this.replace(v1, v2); }

```

but this doesn't

```javascript
String.prototype.test = (v1, v2) => this.replace(v1, v2); 

```

because `this` in arrow function belongs to the location of object literal not the function context.

extending the conciseness aspect of arrow function to also allow contextual `this` is the next best thing.

proposal: some people call arrow function "thick arrow", so maybe the thin arrow `->` syntax be the right syntax for it? i'm not sure because i'm not a language designer, so i don't know what would be the best equally concise syntax. i just hope to see "some way" to extend arrow to cover this last piece of puzzle so we can completely get rid of `function { return }` parts from source code.

---

<div class="post-metadata">

**Author:** ![ljharb](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/ljharb/32/8_2.png) [@ljharb](https://es.discourse.group/u/ljharb)\
**Post date:** [December 31, 2023, 10:34pm UTC](https://es.discourse.group/t/the-other-this-for-arrow-function/1885/2 "2023-12-31T22:34:44Z")

</div>

Why is getting rid of that a valuable goal?

---

<div class="post-metadata">

**Author:** ![kasper](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@kasper](https://es.discourse.group/u/kasper)\
**Post date:** [January 1, 2024, 5:11am UTC](https://es.discourse.group/t/the-other-this-for-arrow-function/1885/3 "2024-01-01T05:11:35Z")

</div>

one of the goal of why arrow functions were added to language in the first place was `Shorter syntactical form`. this proposal is to extend that goal so the new syntax (whatever that may be) will just be a short sugar for regular `function` that will support all regular function characteristics which are missing from thick arrow functions i.e. "thin arrow functions" to have their own `this` binding, allow `yield` statements, allow different `this` with `call`/`bind` etc.

---

<div class="post-metadata">

**Author:** ![ljharb](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/ljharb/32/8_2.png) [@ljharb](https://es.discourse.group/u/ljharb)\
**Post date:** [January 1, 2024, 6:13am UTC](https://es.discourse.group/t/the-other-this-for-arrow-function/1885/4 "2024-01-01T06:13:49Z")

</div>

Specifically, for callbacks, where a lexical `this` was needed. Regular functions don't need shorter syntax, and `this`-sensitive functions are pretty out of vogue anyways.

See:

- [https://esdiscuss.org/topic/unbound-arrow-functions#content-6](https://esdiscuss.org/topic/unbound-arrow-functions#content-6)
- [https://esdiscuss.org/topic/expression-closures-as-compliment-to-arrow-functions#content-13](https://esdiscuss.org/topic/expression-closures-as-compliment-to-arrow-functions#content-13)
- [https://es.discourse.group/t/shorthand-for-inline-functions/926](https://es.discourse.group/t/shorthand-for-inline-functions/926)
- [https://esdiscuss.org/topic/arrow-syntax-unnecessary-and-the-idea-that-function-is-too-long](https://esdiscuss.org/topic/arrow-syntax-unnecessary-and-the-idea-that-function-is-too-long)
- [https://esdiscuss.org/topic/automatically-binding-extracted-methods#content-6](https://esdiscuss.org/topic/automatically-binding-extracted-methods#content-6)
- [https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks](https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks)