-
Notifications
You must be signed in to change notification settings - Fork 15
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: