all/any: Return value for empty arrays?

[m-mohr]

Process ID: all / any

Describe the issue:
The processes all and any return null for empty arrays in openEO

I think the thought was to express that an empty array means no-data, e.g. all([]) -> null, but also all([null], ignore_nodata = false) -> null (here: null = no-data value). So that an empty array has the same meaning as an array with solely no-data values (if not ignored).

This still makes sense, but it is not consistent with common languages though:

	all([])	any([])	Note
Python	true	false
R	true	false	use c() instead of []
Julia	true	false
JavaScript	true	false	all is [].every(x => x) and any is [].some(x => x)
Java	true	false	all is allMatch and any is anyMatch

Note: in JS all is [].every(x => x) and any is [].some(x => x)

According to ChatGPT this is also the case for C++, C#, Ruby, Haskell, Perl, Groovy, Scala, and Kotlin.

ChatGPT also says:

The choice between returning True/False or NoData depends on the context of the application and the specific requirements of the data processing or logical evaluation being performed. In most programming scenarios, True/False is preferred for its logical consistency. However, in data analysis, scientific computing, or situations where the distinction between "no data" and "a definitive answer" is significant, returning a NoData value might be more appropriate.

Proposed solution:
We should discuss whether to update all to return true and any to return false for empty arrays. I'm not sure myself.

[m-mohr]

I've checked more cases and although SQL aggregations return NULL for empty arrays, all environments that I checked return boolean values for all/any. As such, I think we should follow and not implement our own behaviour, which would also somewhat make implementation more difficult.

I'd assume currently mostly no code would rely on this behavior anyway?

[soxofaan]

I support changing all/any to return true/false on empty array.
It makes things more consistent/predictable overall