Regarding the original idea: Why use a whole bit, when you only need one
value out of all possible type's values? For example, for floats, one of
the NaNs could be used for this purpose without any issues with overflow as
would happen in your proposal.
Regarding "which types?": Perhaps this should be controlled via another
built-in trait, such as the following:
trait Invalid {
fn invalid() -> Self;
}
The compiler could then perform option space optimization for any type
implementing 'Invalid'.
On Fri, Apr 4, 2014 at 12:13 AM, Tommi <rusty.ga...@icloud.com> wrote:
> 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 <co...@octayn.net> 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 <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
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
