If you open the source code here then you will find that it is a simple reduce operation staring with false as accumulative value. So when your list is empty then it gives your false. The same for all? it starts with true and empty list doesn’t trigger the iteration process.

Those functions are really well documented.

For Enum.all?/2:

When an element has a falsy value ( false or nil ) iteration stops immediately and false is returned. In all other cases true is returned.

For Enum.any?/2:

When an element has a truthy value (neither false nor nil ) iteration stops immediately and true is returned. In all other cases false is returned.

As you can see in both functions documentation says what happens in “all other cases”.

Maybe it could be seen as confusing, but when you think more about it then it makes more sense.

1. In Enum.all?/2 case we check if all elements passes check and since there are no elements it acts like all elements passes. Please look at it like that: we have 0 items and 0 items passed, so all items passed - or in another words there was no item which does not passed.

2. In Enum.any?/2 case we check if any element passes check and since we have no element no element from list passes check, so we are getting false here. Please look at it like that: we have 0 items and 0 items passed, so no items passed - or in another words there was no item which have passed.

You can notice all items passed vs no items passed parts and that’s correct since we have all? vs any? naming.

Logic is exactly the right word! The answer here has to do with the relationship between the existential and universal quantifiers. Formally:

In regular language, it’s saying that if for all x some proposition P(x) is true, then it’s false that there exists any x such that P(x) is false. Enum.all? is equivalent to the universal quantifier, and Enum.any? is equivalent to the existential quantifier. Let’s play with it!

iex(3)> Enum.all?([2,4,6], fn x -> Integer.is_even(x) end)  
true
iex(4)> !Enum.any?([2,4,6], fn x -> !Integer.is_even(x) end)
true

This makes sense. If all of the integers are even, then obviously not any of them are not even. The high level relationship to keep in mind here: Enum.all?() == !Enum.any?(). If one is true, the other must be false.

Let’s focus on the Enum.any?([2,4,6], fn x -> !Integer.is_even(x) end) bit. The idea here is that we’re looking for any item that passes our test. If no item passes the test, we should return false.

iex(5)> Enum.any?([], fn x -> !Integer.is_even(x) end)      
false

If we give it an empty list, then no possible item can pass the test, so it returns false. Our high level relationship from earlier told us that Enum.all?() == !Enum.any?(). Therefore if Enum.any? returns false with an empty list, then Enum.all? must return true for an empty list.

Thanks for time you took to document here with well explanation.

I almost read your content enough times to digest the intention behind those functions.

Now I got confusion to use Enum.all? I have to check for list emptiness before applying. There is no problem with Enum.any? here but Enum.all? confused with the sounds it has. I thought Enum.all? must evaluate the condition function given to not falsy Since we don’t pass any value in the list, as the priority check, the functional condition is no way it gets executed.

At higher level of understanding I thought it should be false while coming to lower level it is more sense to be true after looking your points.

So, for Enum.all? an extra check has to performed for Non Empty list. Before its actual usage.

As an experience, I thought it to be reverse.

Thanks for Everything

Glad you took the time and effort to document this. Appreciate that.
It’s more explanatory and ideal to look into.

The relationship between the existential and universal quantifiers is self-explanatory for the logic behind the function.

If all of the integers are even, then obviously not any of them are not even. The high level relationship to keep in mind here: Enum.all?() == !Enum.any?() . If one is true, the other must be false.

This explains the hidden logic.

But needs bigger mind.

Thank you

Honestly in 90%, maybe more, of cases you shouldn’t need to check if the list is empty before doing Enum.all?.

I have never to my memory written a check for emptiness in front of any list.all function in 20 or so years of coding.

Yeah! I used to code it so unless I met with the strange behavior or business requirement.

No doubt that we learn from Experiences.

As a Logic in Computing professor, it is great to see a direct application of what I teach!

Another way to describe it is it that all is a series of conjunctions (and) whereas any is a series of disjunctions (or), and by De Morgan’s laws not (A and B) = not A or not B

should it be said like:

Please look at it like that: we have 0 items and 0 items passed failed, …

instead?