Tighten signature of `iszero` and `isone` fallbacks?

[lgoettgens]

This originally came up in oscar-system/Oscar.jl#4574.

The fallback implementations of iszero and isone currently look like this:

iszero(x) = x == zero(x) # fallback method
isone(x) = x == one(x) # fallback method

This of course makes sense of x::Number, but there are a lot of other types defining a zero(::T) that is not that useful to be used in iszero(::T) like this.

I think a very prominent example would be iszero(Int) that compares Int with zero(Int) (which is 0) and returns false.

In the context of oscar-system/Oscar.jl#4574, the problem with this fallback is that people might try to use iszero(R::Ring) to check if R is the zero ring, but the fallback tries to compare R to the zero element in R. Since this is very similar to the Int case above, we wanted to mention this here to see if there is any chance to restrict the signature of the fallback method to something like ::Number. If there is no complete opposition against this, I could provide a PR implementing this, so that we could run a PkgEval so look for how breaking this change would be to the ecosystem.

cc @fingolfin

[fingolfin]

Just to say, I believe in the library it would be sufficient to provide these for Number and AbstractArray (though I did not test this). But of course some packages might rely on this?

[fingolfin]

No reactions from anyone so far. Perhaps best to just create that PR and try?

[jonas-schulze]

IMO, the fallback is useful regardless. For the use case you anticipate, why don't you simply define iszero(::Ring)?

Tightening the type signature practically removes functionality. This is breaking, i.e., this must not happen in a v1 release.