Closed Enyium closed 8 months ago
I think it's because Primint
is simply older -- all of the OpAssign
traits were "only" stabilized in Rust 1.8.0, and it's a breaking change to add more requirements to PrimInt
since it's not a sealed trait. But you could make your own extended trait that requires more, something like:
trait MyPrimInt: PrimInt + BitOrAssign + ... {}
impl<T: PrimInt + BitOrAssign + ...> MyPrimInt for T {}
Don't you gather breaking changes to perform them one day?
In theory, yes, but in practice I'm afraid that a breaking semver bump will fracture the ecosystem, since these traits are often used in others' public APIs.
Hm, I guess I'll close this then.
PrimInt
already has bounds forBitOr
etc. Is it an oversight that the...Assign
variants are missing?Currently, I can do:
...but not:
...when
t
has aPrimInt
bound andcontainer
is initialized withT::zero()
.