Change one to onemult

[timholy]

This is a persistent source of confusion (most recently #36099), and there are incorrect definitions of one scattered across the ecosystem. (We're still deprecating them in Colors-world.) The best answer is to @deprecate one onemult and simply not have a function called one.

[kimikage]

What about adding the 2-arg identity(op, x)?

Edit
As you know, this comes from #16116.

[kimikage]

I think onemult will just change the FAQ to "Why can I use zero but not one? It's inconsistent!" 😛

[timholy]

What about adding the 2-arg identity(op, x)?

"Why is there oneunit but no zerounit?" 😛

[benninkrs]

This ship has probably already sailed, but I've often thought that zero and one should be instances of singleton types Zero and One, representing the typeless concepts of additive and multiplicative identity with fallbacks like +(::Zero, x) = x and *(::One, x) = x. Related discussions: #8092, #16116, #18367, #20561.

[stevengj]

but I've often thought that zero and one should be instances of singleton types Zero and One

This would make a lot of functions type-unstable. e.g. sum(T[]) returns zero(T), so returning Zero() instead would make sum type-unstable (since the type of the result would differ for empty vs. non-empty arrays of the same type).

[benninkrs]

Of course if the type is known then one should return the zero element of that type. I’m thinking of cases where the type is not known.

But even if it were used in general, the return type would be Union{Zero,T}. I was under the impression such small unions are now reasonably performant.

[tkf]

Singleton zero is discussed in #34003. I also mentioned other identities there too.

I think it's better to focus on onemult in this issue.

[perrutquist]

How about deprecating to Base.reduce_empty(*, T) (which already exists) instead of onemult(T)? The only place where you really need this is as the return value of empty reductions.

In all other cases (that I can think of) you can either use true or oneunit.