I have a suggestion. Let's add new primitive data types: i7, i15, i31, i63, u7, u15, u31, u63, f31 and f63
Those would behave exactly like the integral data and floating-point data types: i8, i16, i32, i64, u8, u16, u32, u64, f32 and f64 ...except that the new data types would come with the (unchecked) promise that the high-order bit of each of those new data types' representations would never be set to 1 (with the floating-point types it would be the high-order bit of the exponent). That would reduce the range of values the user is supposed to represent with those types. But the new types would give rise to an optimization for Option<X>, where X is one of the new primitive data types: Option<X> wouldn't need to use extra memory for a separate tag, but could simply use the high-order bit as a tag to indicate the None case. If a user assigns a value which sets the high-order bit of those data types, then it would be considered a logical overflow (even though the actually representation hasn't overflown) and Some(x) where x is such a logical overflown value would be None (which, to me, kind of makes sense). _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
