Interaction of addition and checked conversion

[Keno]

Consider for example:

julia> 0x00007ffea27edaa0+(-40)
ERROR: InexactError()
in +(::UInt64, ::Int64) at ./promotion.jl:172
in eval(::Module, ::Any) at ./boot.jl:267

julia> 0x00007ffea27edaa0-40
0x00007ffea27eda78

It is understandable why this happens, but the behavior is annoying. At least for integers of the same size, this addition is unambiguous.

[eschnett]

If UInt has wrap-around semantics, then one can argue that converting any Int to UInt should succeed.

[vtjnash]

At least for integers of the same size, this addition is unambiguous

it could be non-trivial, since the result would require a Int65 to hold the intermediate result (or perhaps checked arithmetic as well)

[Keno]

We generally have allowed anything that makes sense on a value-preserving level. If integers are the same size then as long as the result is an unsigned integer, either interpretation (subtraction of 40, or addition of reinterpret(UInt,-40) yields the same result). To @vtjnash's point, I think that's a different issue, because we do allow overflow just fine.

[StefanKarpinski]

We should probably make this work but it can't work by normal promotion/conversion, which is annoying. If we promoted UInt + Int to Int instead of UInt then this particular example would work but others wouldn't.

[yuyichao]

Is there any case (for fixed size integer, {U,}Int{8,16,32,64,128}) that we don't want this to work?

[eschnett]

We have generic comparison routines (comparing signed and unsigned integers). Comparison is very similar to subtraction. Thus one can make the case that mixed signed/unsigned arithmetic should also work.

These comparisons have a slightly more complex implementation since they first test whether e.g. the signed argument is negative (and then returning the obvious result) before performing the actual comparison. A similar approach should work here:

function +(x::Unsigned, y::Signed)
    y<0 && return x - unsigned(-y)
    x + unsigned(y)
end

This isn't quite right yet (since the expression -y can overflow), but the implementation is straightforward.

[JeffBezanson]

Yes, +1 for leaving conversion and promotion alone, but implementing UInt + Int to handle this.

[Keno]

Ok, has the decision been made to allow this, in which case I'd like to implement this soon. This is super annoying.

[eschnett]

It seems people like the suggestion in general. It's now a question of looking at the details, which only become apparent once there is a concrete implementation (read: "pull request").

[StefanKarpinski]

x-ref: #9292

[JeffBezanson]

@StefanKarpinski proposes this basic approach here:

function $op(a::A, b::B) where {A<:BitSigned, B<:BitUnsigned}
    T = promote_type(A, B)
    return $op(a % T, b % T)
end

In other words, use % instead of convert for mixed-signedness operations.

[StefanKarpinski]

The reasoning is that we don't check for overflow on arithmetic operations so checking for conversion errors when promoting to a common type but then allowing that operation to overflow is silly – you may as well just guarantee that the result is correct in the modulus of the result type.