lexikos wrote:To be clear, I wrote it without line breaks so that it would appear as part of the sentence, but the actual code would have line breaks. It would be a standard block of code. I guess you thought otherwise, since I can't imagine why else same-line statements would matter.
It was clear, I mean that allowing a multiline function body after
=> wouldn't add much unless a regular function body had good support for same line statements, hence you could still do your fat arrow with
statements on one line, or at least few. More elaborate code might as well be (nested) functions (an existing feature, hence the
wouldn't add much part).
What is () => { {} } supposed to be?
It should be
() => { return {} }, meaning I made a (logical) mistake, not that it should be interpreted as such by the program.
Object literals are allowed to contain hard line breaks
I over looked that. When
expr is an object literal, it would have to be enclosed in
(), then
(...) => expr with implied return and
(...) => {statements} would work.
[color=#FF0000][b]nnnik[/b][/color] wrote:Yes it adds convenience - it decreases redundance.
Some in your original example (disregarding that you named it), the contrary in my modification of it. I think fat arrow followed by a block of code makes most sense when making unnamed functions outside of all functions. Inside a function or method, a nested function is fine. But sure, I imagine your example
looks better than doing it with
?:.
Cheers.