sum([]) vs reduce(+,[])

[pwl]

In the help, sum(x) is described as a "more convenient" notation for reduce(+,x). There is, however a use case when the two are not equivalent:

julia> reduce(+,[])
0

julia> sum([])
ERROR: no method convert(Type{None}, Int64)

The same goes for prod, but for any the behavior is inverted

julia> reduce(&,[])
ERROR: zero-argument & is ambiguous

julia> any([])
false

I suggest that sum([]) and prod([]) should return 0 and 1 respectively, just to conform with +() => 0 and *() => 1. I don't know what to do with any.

[stevengj]

I would tend to argue for the reverse. Having +() => 0 is just wrong if you don't know what type you are adding.

Maybe reduce(op, x) on an isempty(x) should return op(eltype(x)) rather than op(), and define +(T) to zero(T)+zero(T).

[stevengj]

See also #6069.

For single-element collections, we could also define op(x[1]) to return the appropriate type (possibly promoted). This would also further simplify #6116.

[JeffBezanson]

It seems like a good idea to get rid of +() etc. Calling operators with no arguments in some cases is probably not the right convention.

[JeffBezanson]

Also, any and all are strictly boolean, so they are well-defined on empty collections.