Okay. But first I'd like to get some input on for what types T should the language guarantee this suggested optimization for Option<T>. Because the optimization could be done for any type T from which at least one or more of these new primitive data types is accessible. But it's not clear whether or not it should be done if accessing one of those has to go through one or more indirections. I assume that if at least one of these new primitive data types can be accessed through T without any indirections, then it always makes sense to do this optimization.
On 2014-04-04, at 03:37, Corey Richardson <[email protected]> wrote: > 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 <[email protected]> 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 <[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 > > > > -- > http://octayn.net/ _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
