Personally I think a function like this is easy enough to implement for our own codebases if we need one. I don’t think there is much precedence in other langs for such a function and a core implementation is not likely to be any different from what you would write in your codebase, meaning having it in core is unlikely to save anyone from gotchas or improve the performance of their implementation.
To me it feels like bloat. and given that you can already write: not Enum.any?(…) It really doesn’t improve anything much imho. Best Adam On Sat, 18 Jun 2022 at 19:40, Filip Paunkovic <filippaunkovic1...@gmail.com> wrote: > Yeah, I'd like to see this as well. Maybe implement it as a negation of > Enum.any? > > субота, 18. јун 2022. у 19:26:58 UTC+2 urosj...@gmail.com је написао/ла: > >> I'd like this to be added. Just makes sense to do it. My two cents >> субота, 18. јун 2022. у 14:29:49 UTC+2 zvon...@gmail.com је написао/ла: >> >>> @Andrey yeah that is correct but seeing that Enum.filter and Enum.reject >>> exist I thought that Enum.all? should have a counterpart as well. Not just >>> a negated Enum.any? >>> >>> субота, 18. јун 2022. у 13:45:28 UTC+2 br...@grox.io је написао/ла: >>> >>>> !Enum.any is what you are looking for. Also, Enum.any? takes an >>>> optional function, so Enum.any?(list, &! &1) works, as does Enum.any?(list, >>>> fn x -> !x end). >>>> >>>> -bt >>>> >>>> On Sat, Jun 18, 2022 at 7:36 AM Zvonimir Rudinski <zvon...@gmail.com> >>>> wrote: >>>> >>>>> Seeing Enum.all?/2 being available made me assume there was also an >>>>> Enum.none?/2 (like in Ruby), and I was a bit suprised to learn there >>>>> was no such thing. >>>>> I'm aware that I could just do !Enum.all?/2, but Enum.none?/2 sees >>>>> much nicer to me. >>>>> >>>>> One more argument that I could make is that !Enum.all?/1 == >>>>> Enum.none?/1 is not true in all cases. >>>>> Example: >>>>> If we have [false, true], !Enum.all?/1 will be true, but Enum.none?/1 >>>>> will be false >>>>> >>>>> I would like your thoughts on this one. >>>>> >>>>> -- >>>>> >>>> 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-co...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/elixir-lang-core/0b68e108-825f-49d5-86ec-317caa2a852fn%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/0b68e108-825f-49d5-86ec-317caa2a852fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> >>>> Regards, >>>> Bruce Tate >>>> CEO >>>> >>>> >>>> <https://bowtie.mailbutler.io/tracking/hit/f8218219-d2a8-4de4-9fef-1cdde6e723f6/c7c97460-016e-45fb-a4ab-0a70318c7b97> >>>> >>>> Groxio, LLC. >>>> 512.799.9366 <(512)%20799-9366> >>>> br...@grox.io >>>> grox.io >>>> >>> -- > 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/187f642b-209b-4f99-867d-a3c173962b1cn%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/187f642b-209b-4f99-867d-a3c173962b1cn%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/CADwgC_A7qtDs-C2SCoSUGfzN-Gt6e4pPV5w3212VQ6PbF%2BdfPQ%40mail.gmail.com.
