A couple future compatibility breakage thoughts

[vortexofdoom]

Through working on signed ints, I had a couple ideas about changes that could potentially be beneficial to future maintainability.

• Make Number a 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.
• Possibly change the UInt struct to AInt (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 export UInt as a direct alias for the new type.
• Whatever the end solution is for the structs, I would suggest we mark them #[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.

[danlehmann]

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 Number sealed: 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]

You're absolutely right on the third point, idk why I thought otherwise.

[vortexofdoom]

Tacking another on, the BITS constants for the primitive types are u32 rather than usize, as is the return type for their count_ones and similar methods, and I think that's a reasonable change to make.

[danlehmann]

Agreed!