Disallow rem(x, y::Unsigned, RoundUp)

[sostock]

Fixes #34325.

[kimikage]

The current (master) implementation is buggy. However, considering the promotion, I think the prohibition is too strict.

julia> div(3.0, UInt(2), RoundUp)
2.0

julia> rem(3.0, UInt(2), RoundUp)
3.0 # bug (#34325)
-1.0 # expected

julia> div(3, UInt8(2), RoundUp)
2

julia> rem(3, UInt8(2), RoundUp)
0x0000000000000003 # bug (#34325)
-1 # expected

Just FYI, I implemented some arithmetic operations involving saturating arithmetic in FixedPointNumbers.jl (cf. JuliaMath/FixedPointNumbers.jl#230).

From the perspective of consistency, I would like to relax the restriction.
For example, it might look something like this:

Base.rem(x, y, r::RoundingMode{:Up}) = rem(promote(x, y)..., r)
Base.rem(x::T, y::T, ::RoundingMode{:Up}) where {T} = mod(x, -y)
Base.rem(x::T, y::T, ::RoundingMode{:Up}) where {T <: Unsigned} = y == oneunit(T) ? zero(T) : error()

[sostock]

I agree, the current implementation is too strict. However, I think it’s better to always throw an error in Base.rem(x::T, y::T, ::RoundingMode{:Up}) where {T <: Unsigned}. It seems unfavorable to me that whether an error is thrown depends on the value of y but not on the value of x.

[sostock]

However, other rem methods do not use promotion. Maybe they should? Their return type currently also depends on whether a RoundingMode is passed or not:

julia> rem(Int(5), UInt(2), RoundDown)
0x0000000000000001

julia> rem(UInt(5), Int(2), RoundDown)
1

julia> rem(Int(5), UInt(2))
1

julia> rem(UInt(5), Int(2))
0x0000000000000001

[kimikage]

Ah, good reminder of complicated remainder!
We might want to be a little more cautious about making changes.

[StefanKarpinski]

Seems like fixing this would be more appropriate than disallowing it.

[ViralBShah]

Do we want to get this merged for now?