On 8 January 2014 17:32, 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.

Good point.

> I would find it surprising if var declarations did not
> hoist out of do expressions.

Interesting. I have the exact opposite expectation. And I don't see
what good it would do usability-wise.


>> 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.

It's not only the brevity as such, but having a natural, targeted
language feature. IIFEs are merely an encoding, and as such a
distraction. Like A + -B is brief enough, but I'm sure you prefer
saying A - B.


> 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.

Can you clarify what you mean by "repair"? I hope you don't suggest
that "while (true) { (() => do { break })() }" should magically work.

I may warm up to the extra complexity more easily if somebody could
present at least some compelling use cases. :)

/Andreas

On 8 January 2014 17:32, Mark S. Miller <erights at google.com> wrote:

> strict function declarations don't hoist out of blocks, so the hoisting
> issue is `var` only.

Good point.

> I would find it surprising if `var` declarations did not
> hoist out of do expressions.

Interesting. I have the exact opposite expectation. And I don't see
what good it would do usability-wise.


> 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.

It's not only the brevity as such, but having a natural, targeted
language feature. IIFEs are merely an encoding, and as such a
distraction. Like A + -B is brief enough, but I'm sure you prefer
saying A - B.


> 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`.

Can you clarify what you mean by "repair"? I hope you don't suggest
that `while (true) { (() => do { break })() }` should magically work.

I may warm up to the extra complexity more easily if somebody could
present at least some compelling use cases. :)