Josh Stone
Josh Stone
Adding a new trait impl should be fine! I think it would only be a semver issue if you added a `T: CheckedNeg` requirement to some existing API surface.
I think it will have to be a separate trait, especially because it needs an associated type for the unsigned return. I fear that associated type will also make this...
I think it should probably take `&self` for consistency, especially compared to `Signed::abs`.
Personally, I've come to prefer [divan](https://crates.io/crates/divan), but it's not terribly important either way.
> * The `msrv_1_77` feature increases MSRV to 1.77, which is a typical arrangement (e.g., `serde` features will typically elevate MSRV). If/when `num-traits` advances past MSRV 1.77, this feature can...
> Unfortunately they each need the default implementation provided to ensure this PR isn't a breaking change, which does triplicate the code. Hmm, and that's not easily solved with a...
You should add `T: Debug` if you need it, just as you have for `Clone`. The compiler even suggests that! ``` help: consider further restricting this bound | 6 |...
You could define your own extended trait: ```rust trait MyNum: num_traits::Num + Clone + Debug {} impl MyNum for T where T: num_traits::Num + Clone + Debug {} ```
That's mainly an artifact of history, since `Float` came first, and it's a breaking change to add a super trait. I think it would also cause method resolution ambiguity in...
Note that types like `BigInt` and `BigUint` cannot specify a fixed `NUM_BYTES` at all, and they currently implement these traits from `[u8]` and to `Vec`.