I find it easier to read. Less to read, same (or greater) level of clarity.
As for your question about the bug surface area:
```js
const
formattedInput =
do {
if(isValid(input)){
getFormattedValidInput(input);
postToServerAsync(input); //oops!
}
else{
getFormattedError(input);
}
}
;
```
You might call this "randomly adding code in the wrong place", but can you
imagine a heavily nested conditional algorithm where it's not immediately
clear you're inside a "do" expression?
I think the point of new features should to be to reduce the chances of
bugs overall. I'd be curious if there was a single case of this with
do-expressions, let alone overall.
On Thu, 18 Jan 2018 at 15:30 T.J. Crowder <tj.crow...@farsightsoftware.com>
wrote:
> On Thu, Jan 18, 2018 at 9:51 AM, Naveen Chawla <naveen.c...@gmail.com>
> wrote:
> > const x = (tmp=>tmp*tmp+1)(f());
>
> Sure, that's another way an arrow function (with its attendant overhead)
> could be used for that specific example. Harder to read than the `do` or
> the more verbose arrow I posted, but sure.
>
> -- T.J. Crowder
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
