An object used on the right of the in operator may fail to be compatible with ContainerType

[brendan]

As with the iteration_protocol, an object used on the right of the in operator may fail to be compatible with this type (ContainerType?). Mutable prototypes make it easy to break core language semantics. This is true to some extent in ES1-3, e.g. by overriding Object.prototype.toString or Object.prototype.hasOwnProperty. One way to enforce default semantics would be to say that if the right operand of in is incompatible with iterator::ContainerType?, then in defaults to ES3 semantics. But if we say this, there is no point in defining Object.prototype.contains.

The same argument could be made, as noted above re: Python’s iter probing, for the case where a for-in loop head’s right operand is incompatible with iterator::IterableType?.

Wiki location => proposals:iterators_and_generators

[lth]

Ticket needs clarification.

[brendan]

Ok, I recall Lars caring about this a while ago, but I may have a better argument now:

The iterators and generators proposal specifies protocols for iteration, enumeration, and itemization based on new iterator::get, etc. names for properties in the object being iterated by for-in forms, or contains-tested via in. To preserve default ES3 behavior, the proposal defines DontEnum properties in Object.prototype for these new hooks.

But what if someone deletes those Object.prototype properties? Should for-in and in break? Or should all implementations be required to suppress the structural type test failure and fall back on the default hooks?

If the latter, which seems wise to me, then there is no need for the DontEnum props in Object.prototype. They complicate the spec and require mutation and attribute bit fiddling. Why not simplify and specify *only* fallback on default in case of any structural type test failure?

/be