Josh Stone

For most such things, it's just because nobody needed it yet. However, note that shifting is a bit weird compared to other checked/overflowing/wrapping ops, because `overflowing_shl` and `overflowing_shr` will overflow...

They can go on `PrimInt` if you can figure out generic default implementations.

I think it's reasonable, but it should be clear that this can't help any code that only uses `T: Zero` right now. I do worry that the `S` will make...

For the sake of compatibility, I would write that blanket impl the other way: ```rust impl ZeroFrom for T { fn zero_from(_: &()) -> Self { T::zero() } } ```...

> Now let's say that the type `X` is statically allocated and thus implements `num::Zero` and `Y` is dynamically allocated and thus implements only `ZeroFrom` for some specific `S!=()`. I...

If you're going to add extra `S` implementations at all, I think checking the length is more idiomatic of Rust, whereas accepting *anything* for `S` would be out of character.

Note: I have not considered MSRV bumps to be breaking changes, but I have still been very conservative with them to avoid disrupting dependent crates. This bump is not meant...

> Earlier versions won't see the incompatible updates at all! Now that I have released 0.2.19 (#321), I find that this isn't completely true. Cargo 1.51 through 1.59 will ignore...

The current algorithm came in #216, and I mentioned then: > I honestly expect there's still room for improvement, Help is welcome!

We can't blindly forward to the inherent methods until Rust 1.50, but I'm planning an MSRV bump soon, stay tuned...