Re: [boost] 3-state boolean type

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-08-02 09:00:52

On Thursday 01 August 2002 11:37 pm, Petr Kocmid wrote:
> publicizing value enum, which is now private will allow using switch. The
> question is, if the elegant if(x)..else if(!x)..else... idiom will not be
> broken by optimization on some compilers which presume default language
> semantics ("warning: unreachable code", sounds familiar?). switch would be
> safer for compiler portability, also more readable. This if...else...else
> idiom should be definitely part of the test!

I don't mind publicizing the 'value' enum, but I can't imagine a compiler 
misoptimizing if if(x)..else if (!x)..else idiom. Compilers don't do 
aggressive optimizations like that around function calls (!x requires two 
function calls), and after the inliner the expressions become something very 
unlike x and !x. I'll add in the testcase to see if any compilers do make the 
mistake, though :)

> safe_bool should assert if indeterminate?

Well, safe_bool only has 2 states, so it can't be indeterminate. If you mean 
the conversion to safe_bool, then I disagree. I've found it extremely useful 
to use 'if (x)' meaning 'if x is always true' in my own work, though it's 
very likely that in different domains this isn't as useful. 

> I'd prefer the name change to tristate_bool or multistate_bool respectively
> with namespace logic (I mean boost::logic), which certainly will please the
> purists.

Does the addition of 'state' add that much to the name for the simple, 3-state 
case? The name 'tribool' is so nice and short :)

As for the namespace 'logic', I think its perfectly reasonable if we expect to 
see more logic libraries entering Boost. Otherwise, it seems like overkill 
for such a small utility class.

> Perhaps, if tristate_bool implementation will remain with
> non-customizable indeterminate, multistate_bool could be written  more
> generic way later on?

That'd be my favored path. Get us all to agree on the interface for the simple 
case, then generalize.

> Maybe some type traits should be added for such a 3-state too.
>
> Petr Kocmid

What traits do we need?

        Doug