Implement From<T> for Wrapping<T> and From<Wrapping<T>> for T

[sportzer]

It would be nice if std::num::Wrapping supported From<T> and Into<T>, at least when T is a numeric primitive. I assumed these impls would exist and was surprised to find that they do not.

[ketsuban]

It doesn't explicitly list From, but I suspect this is at least spiritually a duplicate of #32463.

[dtolnay]

Can you point to an example of real code where these impls would be useful?

[ketsuban]

Any real code that uses Wrapping<T> benefits from it being more transparently like the underlying T, including From impls, because the purpose of Wrapping<T> and friends is being explicit about desired overflow behaviour in an ergonomic way while retaining T behaviour.

As a personal example, I dabbled with writing a Game Boy Advance emulator a while back; Wrapping<T> was the correct type for register values and similar, because I knew what the desired behaviour was and didn't need warnings about overflow in debug builds, but (if I recall correctly) the lack of implementations of common traits and methods like rotate_left made it less ergonomic than it could have been.

[dtolnay]

Sure, I agree that rotate_left and stuff would be good. That is tracked in #32463. Do you have an example from real code where converting T -> Wrapping<T> or Wrapping<T> to T using a From impl would have been preferable to not using a From impl?

[dtolnay]

I am going to close this for now. I would be happy to consider an RFC if someone finds concrete use cases that would benefit from From impls.

[sportzer]

I guess for me this was more of an initial impression sort of thing. Using wrapping.into() seemed like a more intuitive way of converting back into a T, although wrapping.0 wasn't exactly difficult to discover once I'd worked out that T doesn't implement From<Wrapping<T>>.

I think part of the problem was that when interacting with the standard library, syntax like Wrapping(0) is more commonly used for enum variants like Some, Ok, or Err, so being able to get the value back out via field access isn't as obvious as you might expect. The fact that wrapping.0 works also feels more like an implementation detail, albeit one which is part of the public API, but YMMV.

[TheHashTableSlasher]

Can you point to an example of real code where these impls would be useful?

Making porting any RNG not the worst experience ever, for starters. Or something like cyclic redundancy checks, which assumes twos-complement arithmetic and depends on a memoized array of coefficients. Basically any code where placing Wrapping() around every integer constant is tedious at best, and destructive of code transparency at worst.

[dtolnay]

@myconix could you link to real code?

[TheHashTableSlasher]

Something like http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/CODES/mt19937ar.c or https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp

[TheHashTableSlasher]

https://github.com/libtom/libtomcrypt/blob/develop/src/hashes/md5.c for a less trivial example

[dtolnay]

• If you were porting any of that code today without From impls, what would it look like?
• If we were to add From impls then what would the ported code look like?

I am trying to see concretely what improvement there would be.

[TheHashTableSlasher]

Right now, Wrapping doesn't allow for operating with plain integers, even literals, That, combined with the fact that there's no succinct way to specify a Wrapping literal, means that EVERY integer literal in those code snippets would need a Wrapping() constructor around it. That's messy and time-consuming, in the very best case.