Language suggestions should go through our new RFC process: https://github.com/rust-lang/rfcs/blob/master/active/0001-rfc-process.md
On Thu, Apr 3, 2014 at 8:26 PM, Tommi <rusty.ga...@icloud.com> wrote: > I forgot to mention that this same space-optimization could be done for > Option<bool> already. > > > On 2014-04-04, at 03:18, Tommi <rusty.ga...@icloud.com> 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 >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
