Crates.io | var_num |
lib.rs | var_num |
version | 0.2.1 |
source | src |
created_at | 2024-07-02 07:24:31.407186 |
updated_at | 2024-07-15 00:57:51.214949 |
description | Variable length number implementation that can be used as a drop in replacement for any number primitive. |
homepage | |
repository | https://gitlab.com/magicfoodhand/var_num |
max_upload_size | |
id | 1289308 |
size | 45,948 |
The idea from this crate was inspired by Rob Pike' - "What We Got Right, What We Got Wrong" talk where he mentions that the int type should've been variable sized, "what if they didn't overflow". This crate was build to be used by rigz_vm/fn_vm, to simplify dealing with numbers.
Variable length number implementation that can be used as a drop in replacement for any number primitive, values are stored in their smallest representation initially (when calling From). For mathematical operations the output value matches the overall type of the left hand side. Assume the following are converted to values first:
i32::MAX - i16::MAX = i16
f32::MAX + u8::MAX = f32 // overflow, TODO #1
The following enums should not be created directly, instead use the From
trait to convert to the desired type.
use var_num::VarNum;
fn main() {
let a: u8 = 255;
let b: f32 = 3.14;
let a: VarNum = a.into();
let b: VarNum = b.into();
let num = a + b;
// num is a VarNum::U16(258)
let num = b + a;
// num is a VarNum::F32(258.14)
}
Float and UInt are left unchanged, but they include all operations available on ints. For ints this crate used checked_* to handle overflow or underflow with a few short circuits to skip the operation.
The BitAnd, BitOr, BitXor, Shl, and Shr operators are unchanged and will not change the size of the value. With the first three operators the size of the value can't change, and there were no other special cases; for the last two I personally don't want my numbers changing size when I shift them (even ints, this may change in a future version).