-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removal of Object type-check from GetIterator() algorithm #746
Comments
Wouldn't it be better for engines to implement what's in the spec? Is there a good reason it can't be implemented? |
@ljharb it can be, but:
|
The usefulness I see is that it effectively prevents anyone from returning a primitive as an iterator, thus discouraging patching of built in prototypes - if the user wants to patch the built in prototype, they'd have to pass |
In @domenic's words, these type checks aren't very common to other parts of the language, so maybe it's a bit weird that GetIterator() behaves this way. Since it's unlikely that anyone will create an iterator method that returns a non-undefined, non-null, non-Object, maybe it's not the right place to discourage manipulation of builtin prototypes. I mostly just want to avoid growing bytecode, since we want to keep this stuff as small as possible, and since most implementations don't implement it as spec'd in the first place, it's not breaking anything to change this. |
There are other unexpected type checks in iteration whose motivation is hard to discern, for example if a |
In general these type checks are very surprising to me, given that we allow primitives in most of JS, e.g. by using GetV(). |
IIRC @allenwb had a consistency argument. Was it something like, that we would have these object checks in other cases where we use the object, so they should be extended to cases where we don't? |
I'd be interested to hear such an argument. To me, consistency cuts in favor of removing the checks, given the widespread use of GetV(), including how it is used by Invoke(). We certainly have no precedent of saying "methods must be invoked on objects, not primitives" and I'd say we in fact have the opposite precedent. For example, |
there is no point where GetIterator() is used that its return value isn't immediately used as an object (either by IteratorStep() or IteratorClose(), which both perform GetMethod() or Invoke(), which defer to GetV as said above)) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@caitp this seems like it should be a Needs-Consensus PR, and then we can discuss it in the meeting. Any interest in filing it? |
I likely won’t have time to put that together |
The
If Type(iterator) is not Object, throw a TypeError exception.
step is generally not implemented by engines, see https://jsfiddle.net/gj3uaw1t/ for an example. V8 does implement this step foryield*
, but not other uses of GetIterator().It would be cool if we could remove this from the spec and have common behaviour among implementations (it seems a recent version of SpiderMonkey has added the typecheck, breaking compatibility between FF and Chrome/Safari in this very unlikely situation).
The text was updated successfully, but these errors were encountered: