Re: [boost] [outcome] Ternary logic -- need an example

Subject: Re: [boost] [outcome] Ternary logic -- need an example
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-15 21:42:53

>> 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/