> On Apr 7, 2015, at 10:09 AM, Alan Schmitt <[email protected]>
> wrote:
>
> Hi Allen,
>
> On 2015-04-06 02:08, Allen Wirfs-Brock <[email protected]> writes:
>
>> Alan,
>>
>> I freed up a couple minutes for a quick look at this. I want to spend some
>> more time look at it deeper as this is an area where I made some fixes just
>> a couple weeks ago and I want to review them again to make sure everything is
>> as intended.
>>
>> But, for now a quick answer to your question is: yes there is an
>> intentional difference.
>>
>> For blocks that are not part of loops (and top level StatementLists) we
>> wanted
>> to preserve the legacy completion values described in the NOTE at the end of
>> 13.1.13. this requires preserving empty completion values originating from
>> stand-alone blocks. However, we also wanted all control flow statements to
>> always produce a non-emptry completion value.
>
> I understand. In fact, it seems that this particular behavior did not
> change between ES 5 and ES 6: block evaluation guarantees the last value
> computed is returned, whereas loops don’t.
Well, they do for normal loop completions (according to the spec.) but not for
breaks. I this the latter is a bug. In particular, I think it is pretty
obvious that:
eval(“ {0; while (true) {1; break}; 2}”)
should evaluate to 1
It is a little less obvious for:
eval(“{0; L: while (true) {1; while (true) {2; break L; 3}; 4}; 5}”)
but, I think that consistency with the first case requires this to evaluate to
2.
So, it’s arguably a bug that the ES6 spec. hasn’t changed in that regard
relative to ES3/5. This is something that I can fix before submitting the
final draft to Ecma net week.
> According to my tests,
> neither V8 nor SpiderMonkey have this behavior:
>
> var c; a: { c = 1; while(true) { if (c) { c=0; } else { break a; } } }
>
> returns 0 in both, whereas the spec says it should be 1 (caveat:
> I tested in a current Chrome and Firefox browsers, I don't know if it's
> the correct environment to do such tests).
Doesn’t seem to match either ES3/5 specs or current ES6 drafts. I don’t know if
this is old, non-conferment behavior or new attempts to implement “completion
reform” that didn’t take the actual (evolving) ES6 spec. into account.
>
> Does this inconsistency matter?
Probably. In ES6 we are trying to “reform” completion values so, among other
things, program transformaions do have to worry too much about breaking the
specified specified completions values.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
