Sorry for rising this subject again, but I am somewhat vexed about the
changed decision for the exception throwing when null is passed to the
for..of statement. I know, that my writing here wont change it now, but I
am a little bit uneasy about this dangerous precedent. So why it should not
throw
It sounds like the the tide is swinging towards bug finding rather than
consistency in this case. I'm fine with and and will update the spec.
accordingly.
The conclusion here wasn't exactly clear to me. Is it the following?
- for-in continues to do zero iterations
- for-of throws a
On Jun 17, 2014, at 1:53 PM, Domenic Denicola wrote:
It sounds like the the tide is swinging towards bug finding rather than
consistency in this case. I'm fine with and and will update the spec.
accordingly.
The conclusion here wasn't exactly clear to me. Is it the following?
-
On Jun 12, 2014, at 5:01 PM, Jeff Walden wrote:
On 06/12/2014 03:25 PM, Brendan Eich wrote:
Actually, if memory serves, IE JScript tolerated null and undefined on right
of for-in. SpiderMonkey and my ur-JS implementation, Mocha, did not. Someone
with the jwz nostalgia Netscape 2/3
Somehow I missed when we decided to allow null/undefined as the iterable
value in for-of loops.
The following test passes using the spec algorithms:
var c = 0;
for (var x of null) {
c++;
}
assert.equal(c, 0);
However, if we get a null value here we are most likely just masking an
user bug.
I
On Jun 12, 2014, at 2:36 PM, Erik Arvidsson wrote:
Somehow I missed when we decided to allow null/undefined as the iterable
value in for-of loops.
The following test passes using the spec algorithms:
var c = 0;
for (var x of null) {
c++;
}
assert.equal(c, 0);
However, if we get
On 06/12/2014 03:05 PM, Allen Wirfs-Brock wrote:
I believe this behavior for for-in was added in ES5. My recollection was
that Doug Crockford pushed for it. I don't recall if it was because it
matched web reality or simply because he thought it was a good idea.
It was added for web
On Jun 12, 2014, at 2:36 PM, Erik Arvidsson wrote:
/ Somehow I missed when we decided to allow null/undefined as the iterable
value in for-of loops.
//
// The following test passes using the spec algorithms:
//
// var c = 0;
// for (var x of null) {
//c++;
// }
// assert.equal(c,
Corrected link: https://bugs.ecmascript.org/show_bug.cgi?id=2737
On 6/13/2014 12:16 AM, André Bargull wrote:
On Jun 12, 2014, at 2:36 PM, Erik Arvidsson wrote:
/ Somehow I missed when we decided to allow null/undefined as the iterable
value in for-of loops.
//
// The following test
Jeff Walden wrote:
On 06/12/2014 03:05 PM, Allen Wirfs-Brock wrote:
I believe this behavior for for-in was added in ES5. My recollection was
that Doug Crockford pushed for it. I don't recall if it was because it matched
web reality or simply because he thought it was a good idea.
It was
On Jun 12, 2014, at 3:18 PM, André Bargull wrote:
Corrected link: https://bugs.ecmascript.org/show_bug.cgi?id=2737
On 6/13/2014 12:16 AM, André Bargull wrote:
On Jun 12, 2014, at 2:36 PM, Erik Arvidsson wrote:
Somehow I missed when we decided to allow null/undefined as the iterable
throw. Fast fail is better.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 06/12/2014 03:25 PM, Brendan Eich wrote:
Actually, if memory serves, IE JScript tolerated null and undefined on right
of for-in. SpiderMonkey and my ur-JS implementation, Mocha, did not. Someone
with the jwz nostalgia Netscape 2/3 browsers, please test.
Hmm. I'm reciting tribal knowledge
13 matches
Mail list logo
