I forgot to mention that this same space-optimization could be done for Option<bool> already.
On 2014-04-04, at 03:18, Tommi <[email protected]> wrote: > 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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
