Posted 2013-08-12 04:31:00 GMT
std::optional is a proposal for the C++ standard mirroring Haskell's Data.Maybe.
This elegantly avoids the problem of passing around pointers to doubles or having weird flag values.
In a way, a std::unique_ptr with a nullptr contents is also an odd flag value, and in fact that flag value might already have some contextual significance (e.g. an unused slot in a finite pool), so it would be fine to fit a unique_ptr into a std::optional. But sadly it does not support such types that only have constructors from rvalues, originating as it does from boost::optional which predates move semantics.
Would be great to get this fixed (should be possible just by modifying the library proposal). Even better would be if dealing with such rvalue constructed types in downstream templates did not need so much explicit machinery!
Post a comment
I believe this should already work (as of the latest draft of C++1y, N3690). It's normal for papers to change between what is in the pre-meeting mailing (which N3527 comes from) and the form actually voted into the draft standard (which was N3672). The latter certainly appears to support move-only types. The former also seems to, but it doesn't emphasize it as much.
There's a reference implementation of the std::optional proposal at https://github.com/akrzemi1/Optional -- it'd be interesting to see how smoothly std::optional<std::unique_ptr<T>> works with that.
Posted 2013-08-12 06:52:28 GMT by Richard Smith