Remove trait inheritance from CheckedAdd/Sub/Mul/Div

[lilyball]

There's no need for these traits to inherit from Add/Sub/Mul/Div.

[thestinger]

If you can perform operations returning Option, then you can also perform ones not returning Option. I don't see a reason to remove the inheritance here.

[lilyball]

@thestinger This was motivated by my desire to impl CheckedAdd for char, though I'm unlikely to actually do that. I still thought it was worth submitting because there's no reason for CheckedAdd to require Add. Your statement that you can always have a non-Option variant only seems to work for types that wrap. Non-wrapping types can't necessarily have an unchecked variant, same with types that have invalid holes within their range (as char does, with the 0xD800-0xDFFF block).

[thestinger]

They can always fail/abort for the None case. This is what the non-Checked variant of division already does.

[lilyball]

That's pretty terrible. I would expect a + b to never fail. Division is more acceptable because everyone knows you can't divide by 0. And that's still not a reason to make CheckedFoo inherit from Foo.

[thestinger]

It inherits from it because it's a superset of the functionality. Trait inheritance makes writing generic code more convenient because you don't need to specify as many bounds. Without at least one example of a type where it's sensible to implement CheckedAdd but not Add, I definitely don't think the inheritance relationship should be removed.

[lilyball]

The only person who has chimed in so far is @thestinger, who is against it. I'm going to assume nobody else particularly cares, and as such I will close this until such time as I find a use for a CheckedAdd that doesn't have Add.