arrow function works "by accident" better than just function thanks to its
trapped context. Still bugs me by design we need to create garbage,
including one-shot functions, in order to inline a try/catch to assign to a
single "pointer"

```javascript
const ES6_PROXY = ()=>{
  try {
    new Proxy({},{});
    return true;
  } catch(o_O) {
    return false;
  }
}();
```
I find the do{} solution more elegant and I believe this pattern `()=>{}()`
will be abused pretty soon and JS will start looking like brainfuck but
that's another story I guess.

Probably no rush needed considering the amount of problems the do{} syntax
might introduce.

Thanks for all thoughts and examples.

Regards



On Wed, Jan 8, 2014 at 8:32 AM, Mark S. Miller <erights at google.com> wrote:

> On Wed, Jan 8, 2014 at 2:33 AM, Andreas Rossberg <rossberg at google.com>wrote:
>
>> On 7 January 2014 20:44, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> > Unless we can identify real implementation issues, the semantics of
>> >    do { }
>> >
>> > should simply be those of a blocks.
>>
>> I don't think this flies anyway. It has to be more like a function
>> body, otherwise var and function declarations would hoist out of it,
>> which would be insane IMO.
>>
>
> strict function declarations don't hoist out of blocks, so the hoisting
> issue is var only. I would find it surprising if var declarations did not
> hoist out of do expressions.
>
>
>
>>
>> What I'm arguing for, then, simply is to make it as much like a
>> function body as possible. (That also matches the current IIFE
>> practice best.)
>>
>> Also, I really would want to avoid examples like
>>
>>   return do { break; }
>>
>> and similar craze.
>>
>> Is there a convincing example where cross-expression jumps would
>> actually be useful?
>>
>
> If all we want is sugar for IIFEs, I wouldn't bother. With arrow
> functions, IIFEs are already a lot shorter. The extra brevity of do
> expressions is not worth it.
>
> What would make do expressions worthy of consideration is if they repaired
> the TCP violations of strict arrow IIFEs, including var, arguments, break,
> continue, return, and especially yield.
>
>
>
>
>>
>> /Andreas
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140108/771d08d7/attachment.html>

arrow function works "by accident" better than just function thanks to its
trapped context. Still bugs me by design we need to create garbage,
including one-shot functions, in order to inline a `try`/`catch` to assign to a
single "pointer"

```javascript
const ES6_PROXY = ()=>{
  try {
    new Proxy({},{});
    return true;
  } catch(o_O) {
    return false;
  }
}();
```
I find the `do{}` solution more elegant and I believe this pattern `()=>{}()` will be abused pretty soon and JS will start looking like brainfuck but that's another story I guess.

Probably no rush needed considering the amount of problems the `do{}` syntax
might introduce.

Thanks for all thoughts and examples.