proposal-array-filtering: Alias problem

To be fair tho, in the first case, that’s because the protocol requires all three of keys/values/entries; in the second two, that’s because the right/left variants were impossible to remove, and ended up effectively deprecated, in annex b.

I don’t think any of those three serves as precedent for this proposal.

In .NET’s LINQ enumerable.Select(x => ...) means a projection (Array.map). People coming from C# would certainly be confused.

Which will mean we will have 2 1:1 methods. My 2 cents are that I support this proposal only if it will ensure that programmers wont have to choose between filter and select.

I think this falls into a linter concern. Certainly seeing mixed use of .filter and .select isn’t ideal, but but giving people the option to choose .select is worth it to both the writer and reader.

Note that we have other aliases already in the language:

• Set.prototype.keys is an alias of Set.prototype.values
• String.prototype.trimLeft is an alias of String.prototype.trimStart
• String.prototype.trimRight is an alias of String.prototype.trimEnd

(That’s not including the aliases from the @@iterator to some other method)

Just popping in to register my dislike of an alias. I’m in favor of reject (or filterOut, or whatever the final name is) though 👍

No, TC39 is considering “making filtering easier”, which means looking at the inverse function (reject or whatever we name it) and others like partition. The proposal reached Stage 1 with this as the direction.

TC39 decided to reject (🥁) creating an alias, so we will not be getting a select. Closing this as resolved.

I really like this idea. So I’ve added it to one of my packages jsmodern for TypeScript users (deno users should never miss this).

I love the idea of a reject method on Array.prototype. Or it could be called filterOut or any other name that makes sense and fits within our existing ecosystem.

The select name makes sense if one comes from a Ruby background, but does not if one comes from a LISP, .NET, Java, or SQL background.

One potential issue I see with reject is that Array.prototype.reject is very different from Promise.reject despite sharing the same name. It could lead to some confusion.

As an aside, if we add reject, it might be appropriate to add partition that could act similarly to https://lodash.com/docs/4.17.15#partition — this also might be out-of-scope.

in IDE’s autocomplete list , I guess the programmers may reason out they will have opposite behavior… 😂

And when reading, when there’s no autocomplete list? Or people who just use and editor and not and IDE (like me)?