Re: Will `for (var a of null) {}` throw an error?
Oops, you're right in these cases. The CheckIterable spec helper seems over-general. Allen? /be Gary Guo wrote: Date: Mon, 22 Dec 2014 21:28:54 -0800 From: bren...@mozilla.org Your suggestion breaks Array.from and TypedArrayFrom. In the spec: 8. Let arrayLike be ToObject(items). A type error will also be thrown since null and undefined are not ObjectCoercible. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Will `for (var a of null) {}` throw an error?
actually, in my working copy of the spec, CheckIterable has already been updated to look like: 1. If obj is undefined or null, then return undefined. 2. Return GetV(obj, @@iterator). where GetV is similar to Get but it boxes non-object values before doing the property lookup When you find issues like this, the best thing to do is to simply submit a bug ticket at: bugs.emcascript.org Allen On Dec 22, 2014, at 4:32 PM, Gary Guo wrote: Actually I propose a change in texts in the specification. CheckIterable ( obj ) 1. If obj is `undefined` or `null`, then return `undefined`. 2. If type(obj) is Object, then return Get(obj, @@iterator). 3. Let box be ToObject(obj). 4. ReturnIfAbrupt(box). 5. Return the result of calling the [[Get]] internal method of box passing @@iterator and obj as the arguments. This is way more too complex. We know that there are three situation: 1. obj is `undefined` or `null` 2. obj is of a primitive type 3. obj is an object In 1, we don't care if it returns undefined or throw a TypeError. In ES6 spec, there are two uses of the undefined returned. One of them passes it as F to Call, the other passes it to ToObject. Both of them will result in TypeError. So we can just let this step throw TypeError instead of return `undefined`. I suggest we can a little bit combine these steps: CheckIterable (obj) 1. Let box be ToObject(obj). 2. ReturnIfAbrupt(box). 3. Return the result of calling the [[Get]] internal method of box passing @@iterator and obj as the arguments. If obj is `undefined` or `null`, the first step will fail and throw TypeError. If obj is primitive, it's boxed. If obj is an object, it is no-op in ToObject. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Will `for (var a of null) {}` throw an error?
On Mon, 22 Dec 2014 21:06:18 +0800, Glen Huang curvedm...@gmail.com
wrote:Ideally it shouldn’t, because its twin `for (var a in null) {}` won’t.
But looking at step 8 in
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofexpressionevaluation-abstract-operation,
when passing `null` to `GetIterator()`, it will throw a type error when the
result of step 2 `CheckIterable(null)`, which is `undefind`, is called in step
3 in the algorithm for `GetIterator()`.
Did I miss something or the current spec does throw an error?
To me since `IsCallable(undefined)` is `false`, so it throws an `TypeError`.
Traceur and V8 will both throw a `TypeError` saying that cannot read property
@@iterator from undefined or null, and Firefox throws a `TypeError` saying that
null have no property. So it should be an error.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Will `for (var a of null) {}` throw an error?
In that case we have a gotcha.
Is there any interest to change that behavior? Since es6 isn’t finial yet.
On Dec 22, 2014, at 9:29 PM, Gary Guo nbdd0...@hotmail.com wrote:
On Mon, 22 Dec 2014 21:06:18 +0800, Glen Huang curvedm...@gmail.com wrote:
Ideally it shouldn’t, because its twin `for (var a in null) {}` won’t.
But looking at step 8 in
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofexpressionevaluation-abstract-operation
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofexpressionevaluation-abstract-operation,
when passing `null` to `GetIterator()`, it will throw a type error when the
result of step 2 `CheckIterable(null)`, which is `undefind`, is called in
step 3 in the algorithm for `GetIterator()`.
Did I miss something or the current spec does throw an error?
To me since `IsCallable(undefined)` is `false`, so it throws an `TypeError`.
Traceur and V8 will both throw a `TypeError` saying that cannot read property
@@iterator from undefined or null, and Firefox throws a `TypeError` saying
that null have no property. So it should be an error.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Will `for (var a of null) {}` throw an error?
for in and for of do completely different things and there is no reason to
expect consistency between them.
This was discussed already; search esdiscuss.org.
On Dec 22, 2014 8:37 AM, Glen Huang curvedm...@gmail.com wrote:
In that case we have a gotcha.
Is there any interest to change that behavior? Since es6 isn’t finial yet.
On Dec 22, 2014, at 9:29 PM, Gary Guo
nbdd0...@hotmail.commailto:nbdd0...@hotmail.com wrote:
On Mon, 22 Dec 2014 21:06:18 +0800, Glen Huang
curvedm...@gmail.commailto:curvedm...@gmail.com wrote:
Ideally it shouldn’t, because its twin `for (var a in null) {}` won’t.
But looking at step 8 in
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofexpressionevaluation-abstract-operation,
when passing `null` to `GetIterator()`, it will throw a type error when the
result of step 2 `CheckIterable(null)`, which is `undefind`, is called in step
3 in the algorithm for `GetIterator()`.
Did I miss something or the current spec does throw an error?
To me since `IsCallable(undefined)` is `false`, so it throws an `TypeError`.
Traceur and V8 will both throw a `TypeError` saying that cannot read property
@@iterator from undefined or null, and Firefox throws a `TypeError` saying that
null have no property. So it should be an error.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Will `for (var a of null) {}` throw an error?
Thanks. Found that discussion, and after thinking about it again, throwing
errors on null/undefined actually makes sense, because it’s impossible to
sliently loop over null/undefined with regular for loop (if you check length
directly) or forEach directly. So throwing an error is actually consistent with
how things work in es3/5.
On Dec 22, 2014, at 9:54 PM, Domenic Denicola d...@domenic.me wrote:
for in and for of do completely different things and there is no reason to
expect consistency between them.
This was discussed already; search esdiscuss.org.
On Dec 22, 2014 8:37 AM, Glen Huang curvedm...@gmail.com wrote:
In that case we have a gotcha.
Is there any interest to change that behavior? Since es6 isn’t finial yet.
On Dec 22, 2014, at 9:29 PM, Gary Guo nbdd0...@hotmail.com
mailto:nbdd0...@hotmail.com wrote:
On Mon, 22 Dec 2014 21:06:18 +0800, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
Ideally it shouldn’t, because its twin `for (var a in null) {}` won’t.
But looking at step 8 in
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofexpressionevaluation-abstract-operation
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofexpressionevaluation-abstract-operation,
when passing `null` to `GetIterator()`, it will throw a type error when the
result of step 2 `CheckIterable(null)`, which is `undefind`, is called in
step 3 in the algorithm for `GetIterator()`.
Did I miss something or the current spec does throw an error?
To me since `IsCallable(undefined)` is `false`, so it throws an `TypeError`.
Traceur and V8 will both throw a `TypeError` saying that cannot read property
@@iterator from undefined or null, and Firefox throws a `TypeError` saying
that null have no property. So it should be an error.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Will `for (var a of null) {}` throw an error?
Actually I propose a change in texts in the specification. CheckIterable ( obj )1. If obj is `undefined` or `null`, then return `undefined`.2. If type(obj) is Object, then return Get(obj, @@iterator).3. Let box be ToObject(obj).4. ReturnIfAbrupt(box).5. Return the result of calling the [[Get]] internal method of box passing @@iterator and obj as the arguments. This is way more too complex. We know that there are three situation:1. obj is `undefined` or `null`2. obj is of a primitive type3. obj is an object In 1, we don't care if it returns undefined or throw a TypeError. In ES6 spec, there are two uses of the undefined returned. One of them passes it as F to Call, the other passes it to ToObject. Both of them will result in TypeError. So we can just let this step throw TypeError instead of return `undefined`. I suggest we can a little bit combine these steps: CheckIterable (obj)1. Let box be ToObject(obj).2. ReturnIfAbrupt(box).3. Return the result of calling the [[Get]] internal method of box passing @@iterator and obj as the arguments. If obj is `undefined` or `null`, the first step will fail and throw TypeError. If obj is primitive, it's boxed. If obj is an object, it is no-op in ToObject. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Will `for (var a of null) {}` throw an error?
Your suggestion breaks Array.from and TypedArrayFrom. /be Gary Guo wrote: I suggest we can a little bit combine these steps: CheckIterable (obj) 1. Let box be ToObject(obj). 2. ReturnIfAbrupt(box). 3. Return the result of calling the [[Get]] internal method of box passing @@iterator and obj as the arguments. If obj is `undefined` or `null`, the first step will fail and throw TypeError. If obj is primitive, it's boxed. If obj is an object, it is no-op in ToObject. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Will `for (var a of null) {}` throw an error?
Date: Mon, 22 Dec 2014 21:28:54 -0800 From: bren...@mozilla.org Your suggestion breaks Array.from and TypedArrayFrom. In the spec: 8. Let arrayLike be ToObject(items). A type error will also be thrown since null and undefined are not ObjectCoercible.___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
