Should zero(::Float) = -0.0?

[TotalVerb]

IEEE defines -0.0 + 0.0 === 0.0 + (-0.0) === 0.0, which means that the additive identity of Floatnn is actually -0.0, not 0.0. This is significant when zero(x) is used as the base of reductions, such as in the below definition:

julia> function naïve_sum(xs)
           σ = zero(eltype(xs))
           for x in xs
               σ += x
           end
           σ
       end

julia> naïve_sum([-0.0, -0.0])
0.0

Another example of this issue is #18336. Is setting zero(Float64) and co. to negative zero a sensible idea? As far as I can tell, the signed zeroes behave very similarly in most contexts, so I suspect there won't be much downside.

[TotalVerb]

I tried this change out to see what would break, and... apparently quite a lot. For some reason, this change is not as trivial as I expected. Tests that failed include hashing and sorting. I'll investigate why the breakages happened.

[TotalVerb]

After further experimentation, I'm convinced that this change will make things worse, not better.

[eschnett]

"Worse" in the sense that -0.0 does not have the desired arithmetic properties, or "worse" in the sense that there'll be a lot of unrelated fallout? Hashing and sorting sound like things that can be sorted out, in particular if respective hashing and sort experts agree that using -0.0 as neutral additive element is a good idea.

On the other hand, Julia's implementation of im as complex boolean constant has several known issues with regard to negative zeros, so if you're encountering any of these, then changing the definition of zero might not help. I recall discussions where the conclusion was that one would need to introduce a special imaginary type to handle negative zeros with complex numbers correctly.

[TotalVerb]

Unrelated fallout. I was hoping that the test failures were trivially fixed (such as by changing === x to === abs(x) in some places), but that does not seem to be the case. I believe they are still "easy" to fix, but I no longer believe it is worth introducing this breaking change.

The problem that I have had little success trying to address is that there is some code that makes the assumption that zero(T) === convert(T, 0). The net gain (that some functions will now return the correctly-signed zero) does not seem significant enough to warrant removing these assumptions.