Relax "in" RHS to allow null/undefined, to match de-facto "for/in" standard

[brendan]

ES4 codifies the "for/in" de-facto standard, of course.

This is a bug-fix to make the "in" operator match "for/in" by allowing its right operand to be null or undefined (in which case it evaluates to false). This change would remove TypeError? throws from ES4 implementations. If any content depends on catching such a throw, it is hard to imagine why (other than crude catch-and-ignore top-levels).

This issue was raised in

http://wiki.ecmascript.org/doku.php?id=proposals:iterators_and_generators#compatibility

Lars and I are in favor of matching "in" and "for/in" here. Anyone opposed?

/be

[lth]

Not worth the bother.

[shaver]

This is all-green in the spreadsheet -- should we reopen? Mozilla plans to change Spidermonkey to permit null/undefined RHS for in, FWIW.

[brendan]

I missed this being WONTFIXed. Since everyone is green (everyone!), and fixing this ticket is no bother at all (it removes error-reporting spec/code in favor of less spec or code to evaluate to false), we should just do it.

/be

[brendan]

ES3 added the 'in' operator but made it throw a TypeError? if the value on the right of in is (quoting) "not an object". That's different from for-in (which was there from the start, ES1 onward) calling ToObject? on the right-side value.

Since IE set the de-facto standard of allowing null and undefined on the right in for-in, the for-in loop cannot throw a type error due to the type of the right-hand value being "wrong" on its face. Making in match in this regard means not throwing for undefined, null, boolean, number, or string (the ES1-3 primitive types) -- not just for undefined and null. Although "not an object" in ES4 excludes boolean, double, and string.

Anyway, I'm still in favor.

/be

[David-Sarah Hopwood]

If this is to be changed, we should do so in ES3.1.