I'm wondering about the rationale for `Iterable.all` returning `true` when called on an empty List: ...

# getting-started

[Lukasz Kalnik]

I'm wondering about the rationale for Iterable.all returning true when called on an empty List:

val list = emptyList<Boolean>()
list.all { it } // true
list.none { it } // true
list.any {it } // false

[Klitos Kyriacou]

Another way of thinking about it is that "all items are X" is equivalent to "there is no item that is not X".

[Lukasz Kalnik]

Yes, but this definition then wouldn't apply to none in the same way 😉

[Vampire]

Counter-question, why should it not return true?
All elements in the list are satisfying the predicate.

[Lukasz Kalnik]

none and any with lambda argument are consistent with the no-argument versions:

list.none() == true
list.any() == false

because they check if the list is empty/not empty.

[Lukasz Kalnik]

I think the question is quite philosophical in the end
"if there are no elements, can we say that they satisfy the predicate?"
We can say for sure "There are no elements that don't satisfy the predicate"

[Lukasz Kalnik]

But you couldn't apply the same logical negation to the current behavior of fun <T> none(predicate: T -> Boolean)

[Landry Norris]

None seems to answer ‘there are no elements that do satisfy the predicate’

[Klitos Kyriacou]

None is always the opposite of any.

[Lukasz Kalnik]

Exactly

[Lukasz Kalnik]

True, it's actually not the opposite of all.

[Lukasz Kalnik]

Good point

[Vampire]

It's not really a philosophical question.
All elements in the list satisfy the predicate.
That there is no actual element that could unsatisfy is not relevant.
All elements that are in the list satisfy the predicate.

[Klitos Kyriacou]

Also, if you wanted all to return false for empty lists, whatever programming language you use, you would have to have special treatment for empty lists. The logical way is to return true, because you iterate the list and return false if you find an element that doesn't satisfy the predicate; if you reach the end of the iteration, you return true. This is the case in most languages, not just Kotlin.

[Lukasz Kalnik]

Yes, this makes the most sense I guess.

[Lukasz Kalnik]

Using all rather to check if there is at least one element that doesn't fulfill the predicate.

[Lukasz Kalnik]

And not to check "do I have any elements and do they all fulfill the predicate"

[Shawn]

Sometimes I wonder if they should just leave a link to this wiki article in the .all() docstring https://en.wikipedia.org/wiki/Vacuous_truth

[Joffrey]

Thanks Shawn, I was literally writing that this has little to do with programming, but it's just how logic/math defines this stuff

[Lukasz Kalnik]

Thanks for the article! That gives a good context for this decision.

[ephemient]

(list + x).any() == list.any() || x
(list + x).all() == list.all() && x
(list + x).none() == list.none() && !x

these identities work for lists of all sizes; if you set list = emptyList() and try different values of x, it is clear there is only one reasonable value for those functions on an empty list