Should Symbol.species be consulted about proposal-array-filtering HOT 4 CLOSED

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.

Make Array#filter and Array#filterOut different in one more case definitely a bad idea.

Agreed. I'm not comfortable making filterOut diverge from filter (besides the obvious). Even if we had consensus on subclassing, I would still argue filterOut should match filter exactly.

from proposal-array-filtering.

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.

from proposal-array-filtering.

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.

from proposal-array-filtering.

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 @@species or this kind of subclassing will remain as it is? Wait some more years for the decision about this proposal and block all proposals that it could affect is a bad idea. Until the new approach is not approved, should be used the way that is a standard at this moment.

It's an array method and @@species pattern was added mainly for arrays.

Make Array#filter and Array#filterOut different in one more case definitely a bad idea.

from proposal-array-filtering.