Mention that arrow functions don't need return

[Flimm]

No description provided.

[knpwrs]

As far as I'm aware this only applies to single-line arrow functions. Observe:

[domenic]

Indeed, this PR is incorrect. The expression-bodied case is already covered by the existing text.

[Flimm]

I've corrected the mistake. In master, the example does demonstrate that return is not required for the expression-bodied case, but it does not demonstrate that return is required for the statement-bodied case.

[getify]

Yes, but the point of this project is not to educate on all aspects of JS, not even all aspects of ES6. The point of this project is to highlight in a high-level way what new stuff people can get with ES6. There's tons of nuances to ES6 that aren't even remotely covered here. That's the job of comprehensive ES6 books. FWIW, I have a running list of them here: https://gist.github.com/getify/7ae82fdc2e86bf66bcba

[Flimm]

I'll leave it to committers to decide whether this is a nuance or a pretty essential part of how arrow functions work. I would say it's on the same level of importance as the sentence "Unlike functions, arrows share the same lexical this as their surrounding code."

[getify]

I would say it's on the same level of importance as

The reason I disagree is that "lexical this" is actually a new feature being added to the language -- in fact, it's the primary design motivation for arrows, not just a side effect -- so it clearly deserves to be highlighted. By contrast, the need for return in some cases like with { .. } is a side-effect of grammar rules. return obviously isn't being added to the language here.

[lukehoban]

I made a slight tweak to the description of statement and expression bodies to make this a little clearer in 3d88592.