domenic at domenicdenicola.com (2014-06-17T20:48:40.828Z)
Yup, there was an issue that was reported and fixed fairly recently pointing out that for-of was inconsistent with for-in in this respect. I agree that treating null/undefined as an empty collection has a smell. However, in this case my I agree with who ever it was who reported this. that consistancy between for-in and for-of is what we should have for this condition. BTW, 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.
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 a null value here we are most likely just masking an user bug. > > I assume the justification is that for-in allows null here? However, for-of is new syntax and we have the chance to get this right this time around. Yup, there was an issue that was reported and fixed fairly recently pointing out that for-of was inconsistent with for-in in this respect. I agree that treating null/undefined as an empty collection has a smell. However, in this case my I agree with who ever it was who reported this. that consistancy between for-in and for-of is what we should have for this condition. BTW, 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. Allen > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss