Boost :

Subject: Re: [boost] Ternary logic programming (was: Re: [variant] Maintainer)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-07-02 06:10:43

On 1 Jul 2015 at 21:07, charleyb123 . wrote:

> So, after having looked hard for alternatives, I actually like your syntax
> (because I have a hard time finding a more obvious way to do that with
> if/else).

I ended up a similar place of not being able to think of anything
better than meets the criteria.

> But, I also agree with other comments in this thread that it annoys most
> programmers to demand explicit-comparison-testing-with-bool. We expect
> implicit-bool-conversion, and frankly, it is quite awkward to do a
> three-way-division using a boolean if/else construct.

Ah, I suppose I didn't mention my solution to that yet.

My tribool won't convert implicitly to bool, but anything converting
to a tribool also converts to a bool. So, for monad<T>:

//! \brief Same as `true_(tribool(*this))`
constexpr explicit operator bool() const noexcept;
//! \brief True if monad contains a value_type, false if monad is
empty, else unknown.
constexpr operator tribool::tribool() const noexcept;

So, if we have:

We can do via the explicit bool conversion:

if(a) { execute if a has value }
if(!a) { execute if a does not have value i.e. is empty or
errored/excepted }

This is natural to program against. But if we want the ternary logic
we can also do:

if(true_(a)) { execute if a has value }
if(false_(a)) { execute if a is empty }
if(unknown(a)) { execute if a is errored/excepted }

This is another appeal of the free function based ternary logic
design. You push the implicit bool conversion onto the thing with
tribool state. The library user gets both boolean and ternary idioms
according to their wont.

Does this appeal to the list more? I realise I didn't explain myself
well. As usual.

> I *really* like that you are pursuing it, though. Like pornography, we
> should mostly be able to recognize elegance and expressiveness when
> somebody demonstrates an elegant way to do it.

I have noticed that extremely few find my code nor design elegant nor
expressive :)

We'll see during the AFIO review in two weeks. My main goal between
now and then is to use these monadic futures to make the AFIO API
much more conventional than at present, so I'm hoping to hammer down
a whole load of unexpected rough edges for the conventional Boost
community member. I'm hoping that will be enough to get it passed
review and into Boost.

Niall

```--
ned Productions Limited Consulting
http://www.nedproductions.biz/