Things to consider before releasing 2.0

[IvarWithoutBones]

I wanted to get your opinion on a few things I think we should consider before releasing 2.0, now that we have the chance:

• Need to implement TryFrom<Int> for UInt and vice versa.
• Reconsider how {UInt,Int}::from($primitive | $other_arbitrary_int) works. There's already an open issue mentioning this (u48::From<u64> should not be implemented, and so on; missing truncation function (like as) #37), but the current implementation is rather inconsistent when compared to primitive types. From is always implemented (which means we cannot implement TryFrom), even though using that implementation results in compiler errors if the source's bit width is larger than the target's. This gets inconsistent with signed integers: should UInt <-> Int conversions have the same limitation?
  I think we should switch to only ever implementing TryFrom and return errors if the value doesn't fit. Lossless conversions are more versatile and more consistent with primitives.
• Consider renaming Integer::from_(). Since this method does lossless conversions but From doesn't you can now have confusing situations like these:

  u4::from(0_u16); // Error: bit width of 16 is greather than 4
  u4::from_(0_u16); // This is fine

  I think the method should be renamed to something more descriptive, perhaps something like new_lossless?
• Integer::masked_new doesn't make sense for signed integers. Internally it sign-extends (much like an as cast) without doing any masking. In my opinion the method name should reflect the intent instead of the masking operation, maybe new_lossy?

[dzmitry-lahoda]

For as like conversion can impl feature gated https://github.com/kas-gui/easy-cast?

For literals, did you thought to have simple macro? because 123_u32 to be u33!(123)?

What are you thinking about NonZero?

[CrystalKeck27]

I second the motion to have macros

[dzmitry-lahoda]

const is super macro is simple to add.

i use all 3 things in our codebase of adhoc 48, 63, etc numbers.

ideally things are clarified so it can be more clear possibility of migration.

[dzmitry-lahoda]

@danlehmann can we bump nightly rust version to have this #90 ?

it works fin on stable, why would it fail some 2 and half years old nightly in CI?

[danlehmann]

Removing const_convert_and_const_trait_impl: #93

This should make future changes a lot easier. There's a build breakage (preexisting) - working through that (tracking in #95)

[OpenByteDev]

I would propose removing the panicking methods, since i dont think its intuitive for new() and from_* to panic.