On Sun, Sep 27, 2015 at 3:20 PM, Matt Calabrese
It doesn't. The idea is that the times that you can make such a hook for intrusive_optional are where it is not UB to access that storage regardless of whether or not the object is constructed. For instance, I use an unsigned char to store the value 0 through 51 and I know that this is at the start of the storage location for the card. As the creator of the card type I can guarantee this (this is why it is intrusive). With that knowledge, I can provide some small, default set of functions that operate on raw storage (not an instance of the card type) but that can do so safely whether the object is constructed or not since I can also via hooks guarantee that there will be an unsigned char in that location regardless.
Expanding on this, while it may sound hairy, in practice it should be able to be not too difficult to compose. For instance, if I make a type that contains a card, yet I did not create that card type itself, assuming that I know "card" supports intrusive optional, I would be able to easily point my own intrusive_optional hooks to the location of the "card" that I contain, and forward the functionality along. This leaves you with a higher-level type that again takes up no extra storage for the optional version, and the original type doesn't need a notion of emptiness. -- -Matt Calabrese