Do-Expressions Proposal Stalled?

Naveen Chawla naveen.chwl at
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:

    formattedInput =
         do {
                   postToServerAsync(input); //oops!

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>

> On Thu, Jan 18, 2018 at 9:51 AM, Naveen Chawla <naveen.chwl at>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list