const x = (tmp=>tmp*tmp+1)(f());

I've not seen a use case for do-expressions that can't already be done more
elegantly. The proposal page certainly doesn't provide it, except for an
opinion about how nested ternaries are "awkward". I've never found nested
ternaries awkward, especially with good indentation:

question1 ?
    answer1 :
    question2 ?
        answer2 :
        answer3


On Thu, 18 Jan 2018 at 14:25 T.J. Crowder <tj.crowder at farsightsoftware.com>
wrote:

> On Thu, Jan 18, 2018 at 8:23 AM, Naveen Chawla <naveen.chwl at gmail.com>
> wrote:
> >
> > Also, I don't find it very readable/clear when reading it in code.
> > Maybe I'm missing the whole point, but the comma operator forces
> > you to wrap each non-expression language construct (e.g. for
> > loops) into a function, which makes the expression itself clearer
> > (in my opinion) than a do-expression.
>
> I believe the point is to allow a series of statements, not just an
> expression as with the comma operator; and (when a block is used with them)
> to provide a local scope for identifiers (which again the comma operator
> doens't provide). Basically an arrow function without the call overhead and
> (tiny bit of) syntactic cruft. E.g.:
>
> With the `do` operator:
>
> ```js
> let x = do {
>   let tmp = f();
>   tmp * tmp + 1
> };
> ```
>
> without the `do` operator:
>
> ```js
> let x = (() => {
>   let tmp = f();
>   return tmp * tmp + 1;
> })();
> ```
>
> or in that particular case:
>
> ```js
> let x;
> {
>   let tmp = f();
>   x = tmp * tmp + 1;
> }
> ```
>
> ...but that wouldn't work if `x` were a `const` instead.
>
> How would you address that with just the comma operator? You need a scope
> for `tmp` unless you want it bleeding into the outer scope.
>
> I also have to say I find the comma operator *very* easy to misuse,
> leading to hard-to-read code. `do` would be clearer in those cases.
>
> > Also, it's very easy to accidentally add code after the last
> > statement, breaking the code and hence causing bugs!
>
> Can you give an example of what you mean by that? Randomly adding code in
> the wrong place is going to cause bugs, yes. :-) I mean, just generally...
>
> I'm on the fence about `do` expressions. Yes, they provide a handy micro
> environment for a short series of statements. But given standalone blocks
> and arrow functions (particularly inline ones that are easily optimized),
> is it really worth overloading `do` with another meaning and adding to the
> human and computer parsing overhead? And encouraging inline logic rather
> than breaking into smaller pieces? I'm a firm "maybe" for now. :-)
>
> -- T.J. Crowder
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/5844bbce/attachment.html>

```js
const x = (tmp=>tmp*tmp+1)(f());
```

I've not seen a use case for do-expressions that can't already be done more
elegantly. The proposal page certainly doesn't provide it, except for an
opinion about how nested ternaries are "awkward". I've never found nested
ternaries awkward, especially with good indentation:

```js
question1 ?
    answer1 :
    question2 ?
        answer2 :
        answer3
```