Do-Expressions Proposal Stalled?

T.J. Crowder tj.crowder at farsightsoftware.com
Thu Jan 18 08:54:51 UTC 2018


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/ec906583/attachment-0001.html>


More information about the es-discuss mailing list