Do-Expressions Proposal Stalled?
naveen.chwl at gmail.com
Thu Jan 18 11:39:51 UTC 2018
I find it easier to read. Less to read, same (or greater) level of clarity.
As for your question about the bug surface area:
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.crowder at farsightsoftware.com>
> On Thu, Jan 18, 2018 at 9:51 AM, Naveen Chawla <naveen.chwl at gmail.com>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss