Invalid trait for space optimization of enums.

[vadimcn]

Proposing to add Invalid trait and use it for Option<T> space optimization. This is an alternative to RFC #36.

[sfackler]

*T is nullable. &T and ~T are not.

[ticki]

Internally, they are (you can do NPO on them too).

[sfackler]

It's not clear to me how this would actually work. How would the Invalid trait be usable by the compiler itself as the type implementing it is being compiled? It seems like it'd either have to compile the crate once, dynamically load it, and then call the set_invalid method for all types that implement it or have some kind of interpreter that'd operate directly on the AST.

[huonw]

With associated items (and const-expr sizeof) something like

trait Invalid {
    static BITPATTERN: [u8, .. sizeof Self];
}

impl<T> Invalid for ~T {
    static BITPATTERN: [u8, .. 8] = [0, .. 8];
}

// ...

might work, although it seems a little peculiar.

[vadimcn]

@sfackler, how is it different from compiler using other built-in traits, such as Deref or Drop?

[sfackler]

The compiler doesn't need to be able to execute an implementation of Drop at compile time. It just inserts calls to it at various points in the compiled program.

[vadimcn]

Invalid would work the same way. Why would it need to evaluate anything at compile time?

[sfackler]

struct MyStruct {
    ...
}

impl Invalid for MyStruct {
...
}

static FOO: Option<MyStruct> = None;

[vadimcn]

Grr, that's annoying. I suppose we'd have to prohibit statics with Invalid, just like we prohibit statics with Drop...

[ghost]

I think this feature should be implemented using a private, associated compile-time constant of the Self type. This INVALID value of Self type must be a compile-time constant for obvious reasons and it must't become part of the public interface of the type which implements the Invalid trait because... well, for obvious reasons. Therefore we need two new features before this "Invalid trait" feature can be implemented: associated constants and private items for traits (although, I think that items inside traits should be private by default). It would look something like the following (assuming the default is still public and thus the priv keyword is needed):

trait Invalid {
    priv static INVALID: Self;
}

struct S {
    n: int
}

impl Invalid for S {
    priv static INVALID: S = S { n: 123 };
}

And, to the question of what exactly are the semantics of a "private" trait method, an associated constant or an associated type, I think the answer is that it should work like this:

1. The constant T::INVALID, where T is a type parameter which implements the Invalid trait, should be accessible only from the module where the Invalid trait is defined and its submodules.
2. The constant S::INVALID, where S is an actual type which implements Invalid, should be accessible only from the module where the trait Invalid is implemented for type S, and its submodules.

Also, I don't think that this Invalid trait feature and the automatic space optimization feature for Option<&T> and Option<~T> are mutually exclusive. We can, and I think we should, have them both.

[pczarn]

I think this feature should be implemented with a type such as Difference<T, Value> but it reminded me of Either<A, B> and we don't need either one when we have enums:

enum OptimizedPtr {
    NotNull(uint),
    invalid NotNull(0)
}

An alternative:

enum OptimizedPtr<T: RawPtr> {
    NotNull(T),
    invalid NullPtr = T::null()
}

[nikomatsakis]

This is an intriguing idea. I have to stew on it a bit, but I like it in principle.

[dobkeratops]

great idea, could this implement a -1 invalid array index type; and in turn operator[] overloaded to take a potentially invalid array index safely returning Some(T) or None

[vadimcn]

enum OptimizedPtr {
    NotNull(uint),
    invalid NotNull(0)
}

Somehow it doesn't feel right to actually instantiate the "invalid" bit pattern as an instance of T. Especially, if T implements Drop (would destructor be invoked on the invalid value? hmm...)

enum OptimizedPtr<T: RawPtr> {
   NotNull(T),
   invalid NullPtr = T::null()
}

Doesn't this suffer from the same problem as my proposal, in that it requires compile-time evaluation of functions? (or, alternatively, it requires "life-before-main" in order to initialize statics).

[nikomatsakis]

At most recent meeting, we decided that while this idea is promising, the RFC is insufficiently fleshed out and hence we are going to close. Most importantly, it seems like the problems of how to handle static bitpatterns needs to be worked out and specified in detail. If you have a revised proposal that handles statics, feel free to re-open. In general, while the problem this RFC addresses is important, we don't feel it's so urgent that we have to draft a design THIS SECOND, and hence we can take some time to work through the details.