Space-optimize Option<T> for integral enum T

[ghost]

No description provided.

[ghost]

Actually, I'd like to change this proposal so that instead of the invalid bit pattern being implementation defined, the compiler should be forced to pick the one with the largest value.

[pnkfelix]

Previously proposed RFC's that seem related: #36, #41. I would recommend participants skim over the discussion of those RFC's, especially why they were closed.

(Note that at least one was marked as "postponed", which means we approve of the overall notion but want to hold off on trying to adopt the approach outlined in that RFC.)

[ghost]

The difference between this and the previous, more general, proposals is that this one doesn't require a change in the language or the standard library. This is just a change in the compiler and all existing code gets this optimization for free. For this reason I figured this proposal had a considerably larger change of getting accepted sooner rather than later.

[ghost]

I would also argue that the programmer shouldn't have to do anything extra to get this optimization. In the future, users will be able to declare that their type T has some invalid representation which should be used by Option<T> and the like to perform similar space optimizations. But this is extra work for the programmer which he shouldn't have to do for integral enum types. Therefore this RFC doesn't depend on what we decide to do later on with the general case. It's the same thing with Option<&U>, i.e. it does the space optimization without the programmer having to explicitly ask for it.

[pnkfelix]

@tommit good point.

It is possible that a change like this actually does not require an RFC per-se, since it should be implementable as a compiler optimization (with perhaps some little bits of runtime support in isolated parts of the runtime).

[SimonSapin]

Note that the memory representation of enums is already undefined, precisely to allow adding this kind of optimization without changing the semantics of the language.

[alexcrichton]

Thanks for the RFC! As @pnkfelix and @SimonSapin have noted, enum representation is undefined to allow for optimizations such as this. In the light of that, it's ok to not have an RFC to implement an optimization.

In that case, I'm closing this.

[huonw]

(You can/should open a bug on the main Rust repo so that this optimisation isn't forgotten.)

[ghost]

I filed this issue over here: rust-lang/rust#14540