-
Notifications
You must be signed in to change notification settings - Fork 5
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
Should Symbol.species be consulted #14
Comments
One more time: this proposal will break the web. Until it will not be rewritten to recommend something for new features instead of removing existing features, it makes no sense to rely on it. |
There is also discussion in https://github.com/tc39/ecma262/pull/2360/files about not encouraging extending builtins. Maybe this will apply to new methods that don't already exist on the web. |
I don't see any decision about the standard new approach - subclassing of instance methods should be completely removed (that is differently a mistake - it's actively used in wild, some examples by the link above), should be an alternative of It's an array method and Make |
I don't want hold up the proposal by trying to trailblaze, and we've seen other proposals fail to reach consensus because they try. Until there's full consensus on the subclassing (or what level of subclassing) by the committee, I think making Array methods that don't allow species is a mistake.
Agreed. I'm not comfortable making |
Hi! As part of proposal-change-array-by-copy we have been discussing not consulting
Symbol. Species
when constructing the return values.tc39/proposal-change-array-by-copy#33
There hasn't been new methods added to Array since https://github.com/tc39/proposal-rm-builtin-subclassing was presented so the next proposal that does may set a precedence.
The text was updated successfully, but these errors were encountered: