Crate ux2

uX2: A better uX

Non-standard integer types like u7, u9, u10, u63, i7, i9 etc.

When non-standard-width integers are required in an application, the norm is to use a larger container and make sure the value is within range after manipulation. uX2 aims to take care of this once and for all by providing u1-u127 and i1-i127 types (depending on the enabled features) that offer safe arithmetic operations.

<core::primitive::i32 as core::ops::Add<core::primitive::i32>>::add can panic in Debug or overflow in Release, <ux2::i32 as core::ops::Add<ux2::i32>>::add cannot panic or overflow in Debug or Release, this is because it returns ux2::i33. This is applied for all operations and combinations of types in ux2. This allows for more thorough compile time type checking.

use rand::Rng;
let a = ux2::i4::try_from(3i8).unwrap();
let b = ux2::i8::from(rand::thread_rng().gen::<core::primitive::i8>());
let c: ux2::i9 = a + b;
let d: ux2::i4 = c % a;
let e: core::primitive::i8 = core::primitive::i8::from(d);

uX2 types take up as much space as the smallest integer type that can contain them.

Why does this exist? Why use this over ux?

I noticed uX doesn’t seem to be actively maintained and the current code could use some big changes.

So I did what any reasonable developer does and completely re-invented the wheel.

Behold uX2, slightly better in almost every way.

• More functionality, with optional support for serde.
• Better documentation.
• Better CI (e.g. automated changelog)

I’ve already implemented some of the open issues from uX in this library e.g.

• https://github.com/rust-ux/uX/issues/55
• https://github.com/rust-ux/uX/issues/54
• https://github.com/rust-ux/uX/issues/53
• https://github.com/rust-ux/uX/issues/17

Why didn’t I just post a PR on uX?

1. Review: The current PRs don’t seem to be getting reviewed, I wasn’t really confident a PR which completely changes the entire library would be merged. 2. Control: If the maintainer/s of uX are inactive there is nothing I can do, I cannot get PRs merged or fix issue, if I have control I can do this.

Features

The 8, 16, 32, 64 and 128 features enable support up to the types of i8/u8, i16/u16, i32/u32, i64/u64 and i128/u128 respectively.

The compile times increase exponentially, 3s, 7s, 30s, 3m and 46m respectively.

Structs

• ParseIntError
  A mimic of std::num::ParseIntError that can be constructed on stable.
• TryFromIntError
  A mimic of std::num::TryFromIntError that can be constructed on stable.
• i1
  The 1-bit signed integer type.
• i2
  The 2-bit signed integer type.
• i3
  The 3-bit signed integer type.
• i4
  The 4-bit signed integer type.
• i5
  The 5-bit signed integer type.
• i6
  The 6-bit signed integer type.
• i7
  The 7-bit signed integer type.
• i8
  The 8-bit signed integer type.
• u1
  The 1-bit unsigned integer type.
• u2
  The 2-bit unsigned integer type.
• u3
  The 3-bit unsigned integer type.
• u4
  The 4-bit unsigned integer type.
• u5
  The 5-bit unsigned integer type.
• u6
  The 6-bit unsigned integer type.
• u7
  The 7-bit unsigned integer type.
• u8
  The 8-bit unsigned integer type.