It doesn't have much to do with tribool. outcome<T> and result<T> deliberately take a three state based design with an explicit choice of ternary instead of binary state. The original motivation was actually for the basic_monad based, since removed, non-allocating future-promise implementation where we needed a third state to indicate "pending", but it turned out to be very useful in itself for simplifying usage, eliminating writing boilerplate, and acting as an out-of-band signalling mechanism.
Ok, so by "ternary" you mean "eihter value, or error, or just nothing".
It's more than that. Originally before I wrote any code, I drew up the design on a whiteboard with the exact semantics for all possible permutations of all possible operations based on the three state logic. It was there that I decided that the valued state corresponds to ternary value TRUE, the errored state corresponds to FALSE, and the empty state to OTHER. Now that choice is quite controversial. Here on boost-dev we bikeshedded that choice for some weeks if I remember correctly. Many felt that empty should be FALSE, and errored should be OTHER. But I'm sticking to my guns on that, I still think my assignment is the right choice. The OTHER state gets treated as truly other, and it's why it gets the strongest abort semantics of any of the states. It is considered to be the most abnormal of the three possible states by the default actions by observer functions. I can already tell that some people will want me to make the assignment of the default actions customisable by policy class such that empty is not treated so seriously. The good news is that that is very easy to do for any end user (simply write a new policy class and go), but I have chosen to not document it in the docs. If reviewers feel that documenting how to make arbitrary custom editions of basic_monad (soon to become basic_outcome) is important and to be encouraged, I can do that.
But still, in the documentation we can see the "module" `boost_lite::xxx::tribool`: https://ned14.github.io/boost.outcome/group__tribool.html Does this document only an implementation detail? If so, maybe you should dropit from documentation, as it suggests that tribool is part of Outcome's interface. Or maybe it is part of Outcome's interface?
It is part of Outcome's interface, and hence why boost_lite::tribool is documented (I drag it in specially from the boost-lite docs). You'll find on every basic_monad there is: constexpr operator boost_lite::tribool::tribool () const noexcept; This lets you write: outcome<T> v; if(v == tribool::unknown) ...
Also, what do you understand by "module" here?
The choice of the word "module" is imposed by doxygen. For some very odd reason, it places documentation groups under a "Modules" heading. If anyone knows how to tell it to do otherwise, please let me know. Note that I depart for a business trip tomorrow and Wednesday. Expect no replies until Thursday. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/