danlehmann
commented
7 months ago Hey, thanks for looking into this!
It sounds like I should do a 1.2.7 release (which will have a bunch of new functionality like wrapping_add() and friends).
Once that's out, we can do a major version bump and look into some mild breaking changes.
- Making
Numbersealed: Sounds good, but that requires a major version bump. - UInt to AInt: I'm not sure yet how that would look. I think most of the arithmetic would be different between the two types. Given that the library uses macros to emit some UInt functionality (for bitmasking etc) it might also be possible to emit two different types.
- I'm not sure I am following this - isn't
new()already mandatory on those types?
vortexofdoom
Through working on signed ints, I had a couple ideas about changes that could potentially be beneficial to future maintainability.
Numbera sealed trait, not allowing outside implementations of it. It's hardly the only trait in the ecosystem that has functionality like that, and this crate gives an implementation for all its types, so I think it'd be good to seal off. Obviously technically breaking, but unlikely to make a huge impact given what it's used for internally.UIntstruct toAInt(or similar) and share as much functionality as possible between signed and unsigned types once they're implemented. I'm not entirely sure how much that would be yet. This technically might not even have to be breaking if we just exportUIntas a direct alias for the new type.#[non_exhaustive]to make them impossible to directly construct and force users to acquire them through the public API. [If the only constructor was internal, I'd suggest making it a tuple struct since they can be a little comfier to work with, but that's an admittedly frivolous reason and wouldn't be breaking anyway.]The first and last are obviously breaking but once implemented would mean we could change implementation details with much less risk of breakage, and would lend itself to safer/more predictable use cases.