-
Notifications
You must be signed in to change notification settings - Fork 163
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
Introduce an UnenumerableOperations extended attribute #719
Conversation
Thanks for working on this! I have two thoughts:
|
I agree with @domenic. If we want this for modules, but are unsure outside of modules, let's limit it to modules. If we are sure outside of modules, let's make it the default and sprinkle |
I am not sure this is desirable anywhere, but I updated the PR to make this the behaviour for modules. |
1. Let |enumerable| be <emu-val>false</emu-val> if |definition| is an [=interface=] that has | ||
the [{{UnenumerableOperations}}] [=extended attribute=] and <emu-val>true</emu-val> | ||
otherwise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should also be defined for Stringifiers, Common iterator behavior § forEach
and Iterable declarations, like I’m doing in #825.
This PR was motivated by using WebIDL in a way that bridges the gap a bit with JS classes (which might relate to some built-in modules proposals, to facilitate accurate polyfilling) and TC39 conventions. It seems like we're not currently moving in that direction very much at the moment, so leaving this PR hanging (or closing it?) seems like right call. |
Let's close this until we have a concrete consumer. |
Preview | Diff