Boost logo

Boost :

Subject: Re: [boost] Ternary logic programming (was: Re: [variant] Maintainer)
From: charleyb123 . (charleyb123_at_[hidden])
Date: 2015-07-01 23:07:42

On Wed, Jul 1, 2015 at 6:49 PM, Niall Douglas

> On 1 Jul 2015 at 15:53, charleyb123 . wrote:
> > Under an alternative model, the common construct would be something like:
> >
> > void foo(...) {
> > return switch_(...) {
> > ...
> > }
> > }
> >
> > ... and you manage your true/false/unknown cases explicitly. Works great
> > for asynchronous and distributed, and for interfacing-with-hardware.
> That's exactly what Rust does. In fact, you'll find yourself either
> writing match x { patterns ... } or using monadic programming. A lot,
> because there is little other choice.
> Out of interest, what do you think of my free function ternary logic
> programming:
> tribool t;
> if(true_(t)) { /* true */ }
> else if(false_(t)) { /* false */ }
> else if(unknown(t)) { /* other state */ }
> Nobody here seemed to like it. I am looking for something the average
> programmer will notice immediately and not accidentally assume it's
> boolen logic going on here.

I'm uncertain it's possible to reform if/else (a boolean construct) to do
ternary or MVL things. Or more likely, I'm uncertain it's possible to
reform programmers that are trained in if/else as a binary construct.

It's a tricky problem. I think your syntax is the best we can do with
if/else, and the boost::indeterminate() similarly "inverts" the separation
of "unknown" from the "true/false" values.

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

You made a comment in a previous email that your "tribool" approach was
"paranoid" in addressing "unknown" -- YES, TOTALLY AGREE! That's the only
way to do this, or you are totally screwed with the original problem (of a
false assumption expressed through mistaken logic that was not caught by
the compiler).

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.

IMHO, this is the key problem: if/else is just not very composable. Like
the classic book, "The Art of Software Testing" discusses, refactoring
if/else is amazingly tough (and branch analysis is a combinatorial
explosion). It's hard to express and reason about, and refactoring usually
means a rewrite.

We can set up an "if/else-ladder" to otherwise do what a switch would do,
but in the end, switch ends up being more clear-and-expressive. Easier to
support and extend.

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at