<div dir="ltr">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.<div><br></div><div>Arrow functions succeed, for example: by removing nested "this" context, thereby simplifying moving of code around etc.</div><div>Async await succeeds, for example: by linearizing and hence considerably simplifying the building and reading of asynchronous data flows in code.</div><div>Classes succeed, for example: by removing the fiddly overhead in establishing (especially multi-level) inheritance using prototypes.</div><div><br></div><div>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).</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 18 Jan 2018 at 17:16 T.J. Crowder <<a href="mailto:tj.crowder@farsightsoftware.com">tj.crowder@farsightsoftware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>On Thu, Jan 18, 2018 at 11:39 AM, Naveen Chawla <<a href="mailto:naveen.chwl@gmail.com" target="_blank">naveen.chwl@gmail.com</a>> wrote:</div><div>> ...but can you imagine a heavily nested conditional algorithm</div></div><div dir="ltr"><div>> where it's not immediately clear you're inside a "do" expression?</div><div><br></div></div><div dir="ltr"><div>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. :-)</div></div><div dir="ltr"><div><br></div><div>-- T.J. Crowder</div><div><br></div></div></blockquote></div>