True, SQL uses it in a slightly different way and that might be confusing for someone. In this case Enum.accept would be the better choice, or Enum.keep_if.
How do you teach that Enum.filter is the opposite of Enum.reject instead of Enum.accept? I doubt that adding e.g. Enum.accept would have any impact on the learning curve, rather the opposite, unless we continue to add more and more aliases for basically the same thing. In Ruby, there is: filter, find_all, select, keep_if that more or less do the same, plus reject :). True, there would be yet another way to do filtering. Consistency: Yes, people might start using Enum.accept where they would have used Enum.filter before. I'd argue that it could look more consistent in certain cases, where both filter and reject are used to condense an enumeration: [1,2,3] |> Enum.filter(& &1 > 2) |> Enum.reject(& ...) vs. [1,2,3] |> Enum.accept(& &1 > 2) |> Enum.reject(& ...) TBH, I don't like Enum.accept that much in the example above :/. On Sat, Feb 3, 2024 at 9:25 AM José Valim <jose.va...@dashbit.co> wrote: > Correct, Elixir rarely adds aliases, because it adds to the learning curve > (and Enum is already a large module) and it also eventually becomes a > struggle for consistency (this code base must “only use select” or “only > use filter”). > > Plus I personally dislike select because it partially conflicts with SQL, > where it may read as filtering columns from a table but it is also as a > mechanism to perform transformations akin to map. I believe some > programming languages do provide a select with the same meaning as map, so > it would add to the confusion. > > On Sat, Feb 3, 2024 at 09:06 Andrew Timberlake < > and...@andrewtimberlake.com> wrote: > >> I doubt an alias will be accepted. >> >> What’s interesting is that Javascript doesn’t have select or reject, but >> only filter. >> Filter actually works exactly like you say it does in language (both >> German and English) >> >> <what I want> = Enum.filter(& &1 == <select>) >> <what I want> = Enum.filter(& &1 != <reject>) >> >> Just an observation >> >> —Andrew >> >> On February 3, 2024, Michael Neumann <michaelne...@gmail.com> wrote: >> >> Hi, >> >> I am proposing to add Enum.select as an alias for Enum.filter. >> >> Why? In my native language (German), when we talk about "filtering", its >> exact meaning can be context dependent: >> >> - Water filter - Filters substances out of unclean water. (rejects all >> but water) >> - Particle filter - Rejects particles from a gas. Sometimes also called >> an "air filter" >> - Coffee drip filter - Rejects the coffee powder >> >> So it's not always clear what the filter rejects or selects. A *particle >> filter*, *rejects* particles, while a *water filter* *selects* water (it >> actually does not filter water, but dirty water). We also use the verb "to >> filter out" (herausfiltern), which has the opposite meaning of "to filter". >> >> - This ambiguity in my native language, which likely also applies to >> English, makes my brain sometimes spend unnecessary cycles. Dunno if it's >> just me. >> - Coming from Ruby, select seems to be a natural choice >> - While we have Enum.reject, it's natural counterpart Enum.select is >> missing. >> >> IMHO: >> [:water, :bacteria] |> Enum.select(& &1 == :water) >> >> has higher chances to be understood well by beginners over: >> >> [:water, :bacteria] |> Enum.filter(& &1 == :water) >> Regards, >> Michael -- >> You received this message because you are subscribed to the Google >> Groups "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send >> an email to elixir-lang-core+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/28f58f84-7666-4609-89a1-81d8835a0551n%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/28f58f84-7666-4609-89a1-81d8835a0551n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-core+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/CAOwN-EScg6FK6c3G0RMOvkhGUj0J3JRt%3DuEn9-qSzNNpmAe3xQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/elixir-lang-core/CAOwN-EScg6FK6c3G0RMOvkhGUj0J3JRt%3DuEn9-qSzNNpmAe3xQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2B2k-Nqtfj3Hnr9twyK5xuL3QwdL57X%2BP7V6OJfRj-O5g%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2B2k-Nqtfj3Hnr9twyK5xuL3QwdL57X%2BP7V6OJfRj-O5g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAKjimW%2BXthQ4yVy%2BmRQwU6DQjGh-q%3Dhx4VYVtgtZFjVVdyhzRA%40mail.gmail.com.
