You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The fallback implementations of iszero and isone currently look like this:
iszero(x) = x ==zero(x) # fallback methodisone(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.
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?
This originally came up in oscar-system/Oscar.jl#4574.
The fallback implementations of
iszero
andisone
currently look like this:This of course makes sense of
x::Number
, but there are a lot of other types defining azero(::T)
that is not that useful to be used iniszero(::T)
like this.I think a very prominent example would be
iszero(Int)
that comparesInt
withzero(Int)
(which is0
) and returnsfalse
.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 ifR
is the zero ring, but the fallback tries to compareR
to the zero element inR
. Since this is very similar to theInt
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
The text was updated successfully, but these errors were encountered: