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
GetKeysIterator should defer IsCallable check on next #98
Comments
Yeah, makes sense. I'll bring this next meeting. |
same for |
I'm a bit less convinced for |
Yeah, so to be consistent with our choices at the last meeting, we should not validate the interface. |
I am not convinced that consistency with the choice at the last meeting requires that, especially because these are string-named methods and there's multiple of them. An iterator whose Also we did explicitly discuss exactly this question and decided on exactly these semantics. I don't want to revisit that. You can add something to the agenda if you really want to, but I'm not going to.
|
That's fair, but I think you're still obligated to bring it up and reconfirm that plan, given the recent iterator helpers decisions. |
What's the result discussion of this issue? |
@zloirock It was approved. Notes will be out in 2 weeks. |
Specifically, dropping the IsCallable check in GetKeysIterator was approved, but we're keeping the others mentioned above. |
After getting consensus for tc39/proposal-iterator-helpers#274 for iterator helpers, GetKeysIterator here should also defer the IsCallable check.
The text was updated successfully, but these errors were encountered: