Allow Implicit Return of Assignment Expressions

What version are you using? 3.11.1

What did you do? I ran ESLint on an expression in this form: node => this.child = node

What happened? The linting failed because of the no-return-assign rule

What did you expect to happen? No failure

---

The no-return-assign rule was changed to include implicit return for #4743, but I’m not sure why. The rule’s documentation suggests that choosing to return the value from an assignment doesn’t make sense, so the expression is likely to be a mistake:

function doSomething() {
  return foo = bar + 2;
}

It is difficult to tell the intent of the return statement here. It’s possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo?

~But in the case of arrow functions’ implicit return, there’s no implication that the function was meant to return the result of the assignment. It’s just an incidental result.~

~To me, the form I provided at the top seems like the most natural way to write an arrow function that is supposed to perform an assignment and whose return value isn’t used. In my case, the context makes it clear that the arrow function is just a simple callback and the return value isn’t important.~

I could submit a PR with some guidance. Alternatively, if the team decides not to make this change, maybe someone can update the rule’s documentation to explain why it makes sense in these cases.

(This issue is about implicit return, but in case it’s relevant for understanding my point of view, I also don’t understand why this rule applies to types of assignment, like the one above, that don’t evaluate to undefined.)

[platinumazure]

Some of our rules are a little more opinionated than others. Every violation can be fixed by using a block body (for arrow functions), or moving the return statement to the next line after assigning. I don’t see a strong need for a change at all, and I would definitely be 👎 to any change to default behavior (i.e., any change would need to be behind an option).

@eslint/eslint-team Would anyone like to champion this enhancement request?

[Persola]

OK. I’m not going to pursue an option so I’ll just close.

I’ve read the documentation a number of times now, though, and I still don’t understand why the rule even applies in this case. Can anyone explain? Maybe I can rephrase something for clarity.