Idea: Detect policy definitions that would permit a std::optional-compatible-interface

[hostilefork]

Cool stuff...I've done a similar thing myself, in a less general way as outlined in this article.

In my case, the sacrifice of generality was because I wanted the interface to be the same as std::optional (to use as a specialization, so users would not to be aware of it) So I made the contained object "collude" in such a way to guarantee that the only way the special value could be created was by the optional specialization itself.

This is not a guarantee one can make on an int, if you were to give access to it. But there could be a system of friending with particular constructors (as I used) that would achieve it.

So I wonder if there could be a best of both worlds solution. The default could be to assume you shouldn't give a std::optional compatible interface. But then some aspect of the policy could be detected to reassure the compact_optional that it was the only one who had a way to make that pattern in the contained value.

Could that be made to work?

[akrzemi1]

I could make this a long term goal. For now, note that you can wrap boost::optional or std::experimental optional into compact_optional. This way, you can get a uniform (but not that of optional) interface for compressed and uncompressed cases.

In practice, how often in your programs, do you have to do:

*opt = some_T;

?

Regards, &rzej