If you're using x = x.wrapping_add_signed(y), it likely makes sense for x to be of type Wrapping<u32> instead of just u32, but then as things stand you have to perform some gymnastics like x = Wrapping(x.0.wrapping_add_signed(y)), whereas x += y would be simpler and unambiguous. The types u32 and i32 are for example, ideally this would be for all the instances of wrapping_add_signed.
1 Like
For the _signed case, I think it'd be more consistent to have Wrapping::add_signed methods, maybe?
x += Wrapping(1) would fail for x: Wrapping<u16> if you have Wrapping<u16>: AddAssign<Wrapping<i16>> because of details of how type inference for literals works.
Actually I suggest Wrapping<u16>: AddAssign<i16>, not AddAssign<Wrapping<i16>>, so you would do x += 1 directly. But I don't understand how type inference for literals works so maybe that would have the same issue?
1 Like
It would.
Here's a simple example:
trait MyTrait {}
impl MyTrait for i16 {}
fn foo(x: impl MyTrait) {}
fn main() {
foo(1); // This compiles
// But it stops working if you uncomment the below
// impl MyTrait for u16 {}
}
If there's exactly one possible integer type, the literal gets that type. But as soon as there's a second possibility the literal becomes i32 because of integer literal fallback, and then it no longer works.
It's long been a wish to have a way to let things like this work somehow, but no such feature has been designed yet.
5 Likes