Naveen Chawla (2018-01-18T12:01:02.000Z)
I agree it's a misuse, my point is simply why introduce the possibility?
Key question for me (for any feature): show how it can reduce the chances
of bugs.

Arrow functions succeed, for example: by removing nested "this" context,
thereby simplifying moving of code around etc.
Async await succeeds, for example: by linearizing and hence considerably
simplifying the building and reading of asynchronous data flows in code.
Classes succeed, for example: by removing the fiddly overhead in
establishing (especially multi-level) inheritance using prototypes.

The examples on the proposal page don't succeed, for me, in establishing
how (if at all) using a do-expression could (vs the most elegant
alternative currently).

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

> On Thu, Jan 18, 2018 at 11:39 AM, Naveen Chawla <naveen.chwl at gmail.com>
> wrote:
> > ...but can you imagine a heavily nested conditional algorithm
> > where it's not immediately clear you're inside a "do" expression?
>
> I can. I would call it a misuse of the `do` operator, just like it is when
> you do that with conditionals or nested callbacks or switches or arrow
> functions or (etc.), or some combination of same. :-)
>
> -- T.J. Crowder
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180118/544c801b/attachment.html>
naveen.chwl at gmail.com (2018-01-18T12:04:39.960Z)
I agree it's a misuse, my point is simply why introduce the possibility?
Key question for me (for any feature): show how it can reduce the chances
of bugs.

Arrow functions succeed, for example: by removing nested "this" contexts,
thereby simplifying moving of code around etc.

Async await succeeds, for example: by linearizing and hence considerably
simplifying the building and reading of asynchronous data flows in code.

Classes succeed, for example: by removing the fiddly overhead in
establishing (especially multi-level) inheritance using prototypes.

The examples on the proposal page don't succeed, for me, in establishing
how (if at all) using a do-expression could (vs the most elegant
alternative currently), if not the converse.
naveen.chwl at gmail.com (2018-01-18T12:04:15.894Z)
I agree it's a misuse, my point is simply why introduce the possibility?
Key question for me (for any feature): show how it can reduce the chances
of bugs.

Arrow functions succeed, for example: by removing nested "this" context,
thereby simplifying moving of code around etc.

Async await succeeds, for example: by linearizing and hence considerably
simplifying the building and reading of asynchronous data flows in code.

Classes succeed, for example: by removing the fiddly overhead in
establishing (especially multi-level) inheritance using prototypes.

The examples on the proposal page don't succeed, for me, in establishing
how (if at all) using a do-expression could (vs the most elegant
alternative currently), if not the converse.
naveen.chwl at gmail.com (2018-01-18T12:02:35.114Z)
I agree it's a misuse, my point is simply why introduce the possibility?
Key question for me (for any feature): show how it can reduce the chances
of bugs.

Arrow functions succeed, for example: by removing nested "this" context,
thereby simplifying moving of code around etc.
Async await succeeds, for example: by linearizing and hence considerably
simplifying the building and reading of asynchronous data flows in code.
Classes succeed, for example: by removing the fiddly overhead in
establishing (especially multi-level) inheritance using prototypes.

The examples on the proposal page don't succeed, for me, in establishing
how (if at all) using a do-expression could (vs the most elegant
alternative currently), if not the converse.