const VS features detection

Andreas Rossberg rossberg at
Thu Jan 9 06:18:25 PST 2014

On 8 January 2014 17:32, Mark S. Miller <erights at> wrote:
> On Wed, Jan 8, 2014 at 2:33 AM, Andreas Rossberg <rossberg at>
> wrote:
>> On 7 January 2014 20:44, Allen Wirfs-Brock <allen at> 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. :)


More information about the es-discuss mailing list