Optimize storage for Result with NeverValueField

[danakj]

When E in Result<T,E> is a NeverValueField type, we could use that to tell if T or E is present without a third field. We can do this by storing T and Option and using id_none() to signify T is present.

We could technically do the inverse as well when T is a NeverValueField type. With an inverted storage type.

This would let us reuse machinery instead of writing storage again from scratch for Result. Currently it is broken due to no_unique_address usage, showing how it’s better to reuse code here.

Enums

To really benefit we need the error to commonly be a NeverValueField.

• Box is already, I think?
• Enums

Enums are tricky. We an provide a macro that is placed inside the enum which defines the never value. But it can’t add a discriminant to the enum or it would break its use in switch statements. So it can’t really do anything.

Instead we could put the macro below the enum, and it could define a function to be found with ADL that returns the never value. Then the NeverValueField machinery can be specialized for enums to use this.

[danakj]

I forgot when writing this that Result also has a 3rd state: Ok, Err, and Moved (aka holding neither). And Result needs to track this and panic when used in Moved state to not give access to moved-from Ok or Err values. Option on move can be come empty, but Result becomes invalid.

The one case we could optimize storage still is for when T and E are both NeverValueField. Then we could store:

Option<T> ok_;
Option<E> err_;

and when both are empty, the Result is moved-from. And it would not need any additional state.

But we'd need to generalize NeverValueField to handle more than 1 possible value in order to ever optimize the case where only T or only E satisfy NeverValueField.