On Thu, Nov 20, 2014 at 11:00 AM, Andrzej Krzemienski
Note that the proposed expected
has the same "identity crisis": It'll probably face the same resistance. Comparing no value and a value simply doesn't make sense and code like shown is a real bug.
I disagree with this statement. In case of optional<T> having no value of T is deliberately treated as a yet another value. This has a well defined purpose. It is covered in the documentation here: http://www.boost.org/doc/libs/1_57_0/libs/optional/doc/html/boost_optional/q...
By containers you specifically mean map, right? Unordered map for example would not require operator< Containers (maps) always come up as the primary rationale for operator< However, the user could also define his own comparison function for this purpose. Perhaps other use cases of operator< could be presented.
the docs also recommends NOT to use optional<T> to signal a potential error/difficulty in computing T: http://www.boost.org/doc/libs/1_57_0/libs/optional/doc/html/boost_optional/t... .
This is the choice made for optional<T>. The authors of expected
may want to choose a different model. What's wrong with being explicit with what you want, especially in ambiguous situations like those mixed comparisons?
Nothing wrong with that. It is just not the job for optional. Perhaps a job for expected
.
But is it what people have problems with isn't it? -- Olaf