That's a strong hint that those definitions would make our lives easier. But it's not forcing anything?
Also, I don't see why `any([]) == False` would be any more obvious than `all([]) == True`?
I've seen not-so-carefully designed APIs that violate your 'obvious' logic for 'any':
We had a system that you could send a list of topics, and it would return you all the datasets associated with those topics. The designer of the system decided that an empty list of topics would return all datasets, instead of nothing.
I suspect their reasoning was that giving people an option to get all datasets was useful, and that predictably returning nothing was useless.
But what they should have done in this situation for a clean API was to take an optional list of topics.
any([x, y]) == x or any([y]) == x or y or any([])
all([x, y]) == x and all([y]) == x and y and all([])
then any([]) must be false (otherwise x and y would never matter), and all([]) must be true.
In the query API you're describing, does {topic1, topic2} find datasets on (topic1 OR topic2), or is it (topic1 AND topic2)? That's what determines whether more topics means more or fewer results, and whether {} should correctly find nothing or everything.
Also, I don't see why `any([]) == False` would be any more obvious than `all([]) == True`?
I've seen not-so-carefully designed APIs that violate your 'obvious' logic for 'any':
We had a system that you could send a list of topics, and it would return you all the datasets associated with those topics. The designer of the system decided that an empty list of topics would return all datasets, instead of nothing.
I suspect their reasoning was that giving people an option to get all datasets was useful, and that predictably returning nothing was useless.
But what they should have done in this situation for a clean API was to take an optional list of topics.