[section Gotchas] [section A note about optional] `optional` should be used with special caution and consideration. First, it is functionally similar to a tristate boolean (false, maybe, true) —such as __BOOST_TRIBOOL__— except that in a tristate boolean, the maybe state [_represents a valid value], unlike the corresponding state of an uninitialized `optional`. It should be carefully considered if an `optional` instead of a `tribool` is really needed. Second, although `optional<>` provides a contextual conversion to `bool` in C++11, this falls back to an implicit conversion on older compilers. This conversion refers to the initialization state and not to the contained value. Using `optional` can lead to subtle errors due to the implicit `bool` conversion: void foo ( bool v ) ; void bar() { optional v = try(); // The following intended to pass the value of 'v' to foo(): foo(v); // But instead, the initialization state is passed // due to a typo: it should have been foo(*v). } The only implicit conversion is to `bool`, and it is safe in the sense that typical integral promotions don't apply (i.e. if `foo()` takes an `int` instead, it won't compile). Third, mixed comparisons with `bool` work differently than similar mixed comparisons between pointers and `bool`, so the results might surprise you: optional oEmpty(none), oTrue(true), oFalse(false); if (oEmpty == none); // renders true if (oEmpty == false); // renders false! if (oEmpty == true); // renders false! if (oFalse == none); // renders false if (oFalse == false); // renders true! if (oFalse == true); // renders false if (oTrue == none); // renders false if (oTrue == false); // renders false if (oTrue == true); // renders true In other words, for `optional<>`, the following assertion does not hold: assert((opt == false) == (!opt)); [endsect] [section Moved-from `optional`] When an optional object that contains a value is moved from (is a source of move constructor or assignment) it still contains a value and its contained value is left in a moved-from state. This can be illustrated with the following example. optional> opi {std::make_unique(1)}; optional> opj = std::move(opi); assert (opi); assert (*opi == nullptr); Quite a lot of people expect that when an object that contains a value is moved from, its contained value should be destroyed. This is not so, for performance reasons. Current semantics allow the implementation of `boost::opiotnal` to be trivially copyable when `T` is trivial. [endsect] [section Mixed relational comparisons] Because `T` is convertible to `optional` and because `opiotnal` is __SGI_LESS_THAN_COMPARABLE__ when `T` is __SGI_LESS_THAN_COMPARABLE__, you can sometimes get an unexpected runtime result where you would rather expect a compiler error: optional Flight_plan::weight(); // sometimes no weight can be returned bool is_aircraft_too_heavy(Flight_plan const& p) { return p.weight() > p.aircraft().max_weight(); // compiles! } // returns false when the optional contains no value [endsect] [section False positive with -Wmaybe-uninitialized] Sometimes on GCC compilers below version 5.1 you may get an -Wmaybe-uninitialized warning when copiling with option -02 on a perfectly valid `boost::optional` usage. For instance in this program: #include boost::optional getitem(); int main(int argc, const char *[]) { boost::optional a = getitem(); boost::optional b; if (argc > 0) b = argc; if (a != b) return 1; return 0; } This is a bug in the compiler. As a workaround (provided in [@http://stackoverflow.com/questions/21755206/how-to-get-around-gcc-void-b-4-may-be-used-uninitialized-in-this-funct this Stack Overflow question]) use the following way of initializing an optional containing no value: boost::optional b = boost::make_optional(false, int()); This is obviously redundant, but makes the warning disappear. [endsect] [endsect]