Do-Expressions Proposal Stalled?

Naveen Chawla 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:

```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.crowder at farsightsoftware.com>
wrote:

> On Thu, Jan 18, 2018 at 9:51 AM, Naveen Chawla <naveen.chwl at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/62875295/attachment.html>


More information about the es-discuss mailing list