CheckedAdd should probably not extend Add

[popematt]

...and more generally, checked operation traits should not extend their unchecked counterparts.

I'd like to contribute a PR to implement CheckedAdd for the NonZero___ types in std::num, but it is not possible since they do not implement core::ops::Add (for good reason). The way to unblock my desired change is to make CheckedAdd not extend Add.

I suspect that removing the relationship between CheckedAdd and Add might be a breaking change, so I figured I'd propose the idea before I start a PR for it.

The presence of an unchecked add implies that a checked add is possible, but a checked add does not imply that an unchecked add is possible. I think that, if anything, Add should extend CheckedAdd (though I realize the practical difficulties of that). Given the relationship between them, I wonder if the real "right" solution also involves getting checked operations into core::ops. If it is, then I am willing to pursue that course of action instead of making changes to num-traits.

[cuviper]

I suspect that removing the relationship between CheckedAdd and Add might be a breaking change,

Yes, that is a breaking change, sorry.

I wonder if the real "right" solution also involves getting checked operations into core::ops.

Those traits are all related to built-in language operators, so you can impl Add to get a working + operator on your own types. It's not impossible to think of having core traits for more numeric methods, but there's not any current precedent for that. Most of these num traits were in the standard library before Rust 1.0, and were kicked out to live here instead.

[popematt]

Most of these num traits were in the standard library before Rust 1.0, and were kicked out to live here instead.

Do you know where I can find any of the history of that decision?

[cuviper]

I found the commit history, but not much discussion. For this particular trait:

• It was removed with its methods transferred to trait Int in rust-lang/rust@e51cc08
• trait Int was deprecated in rust-lang/rust@232424d
• trait Int was removed in rust-lang/rust@eeb9488
  • and backported before 1.0.0 in rust-lang/rust@0372484

[dzmitry-lahoda]

Can it be done like:

• detect major version change in this crate, so breaking change will be enabled automatically on toml update.
• also allow feature for that switch if somebody wanted. in clap they have something like v5_unstable for example.

[cuviper]

• detect major version change in this crate, so breaking change will be enabled automatically on toml update.

Major version of what? I don't know what you mean here.

• also allow feature for that switch if somebody wanted. in clap they have something like v5_unstable for example.

No, because that makes the whole build fragile if one dependent wants it different than another. And if you really control the whole build, then you can just create a new trait that does what you want.