2017-05-15 17:57 GMT+02:00 Niall Douglas via Boost
This argument can be generalised into the argument in favour of ternary logics over binary logics. Sure, 90% of the time binary logics are sufficient, but binary is a subset of ternary. And *you don't have to use* the "other" state in a ternary logic just because it's there. Just don't use it, so long as its implementation signals its unintentional usage with a very loud bang, it's a safe design.
(There is an argument that Outcome's "very loud bang" isn't loud enough. I'd be pleased to hear feedback on that)
Niall, you mention "ternary logic" here, and I guess it has to do with 'module' `tribool` exposed by Outcome library. But I do not believe I have seen in the documentation (I mean the tutorial section) how I am supposed to use it, and how it improves my programs. Or I might have just missed it. Could you give me an example?
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". 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? Also, what do you understand by "module" here? Regards, &rzej;