From my own experience I cannot but agree. If you're implementing a complex
Hi, I'm reading a draft of a proposal to standarize interval arithmetic (from the authors of Boost.Inverval). They propose to include the specialization "interval<bool>" to represent "false<->maybe<->true", that is, a tristate boolean expressed as an interval in the "lattice" range [false,true] They specifically mention that they propose interval<bool> instead of Boost.TriBool becasue they argue that conversion from indeterminate to bool shouldn't be false but fail with an exception. It turns out that in any actual case I can think of, throwing when trying to narrow an indeterminate tribool into true or false is indeed much prefered than returning false. The tribool documentation says that you should write: if ( b ) certainly_true(); else if (!b ) certainly_false(); else uncertain(); The authors of the proposal argue that even though you should follow that pattern, if you don't, so your code is written like: if ( b ) certainly_true(); else certainly_false(); then if b is indeterminate the false branch should not execute because that's hardly what the programer intended in the case of a tri-state logic. triboolean predicate that nests child triboolean predicates (various levels down), you can rightly decide to use the simplified pattern (with just the 2 certain branches) and let the exception mechanisms wind up the "uncertain answer" up to the caller; but for this you need ideterminate->bool to fail... Of course there is always the choice of using the "correct" pattern that properly test for "certainly false". So, why doesn't tribool throw in this case? Fernando Cacciola SciSoft