[std-interval] separate bool_set proposal available

[Ron Avitzur]

>We have worked on separating the bool_set type (previously named
>interval<bool>) into its own proposal.  Let me remind you that
>this is used as the return type for the comparisons of intervals,
>and it implements multi-valued logic (akeen to Boost.Tribool).
>
>It is going to be document number N2046 in the mid-term mailing.
>The PDF is available at :
>http://www-sop.inria.fr/geometrica/team/Sylvain.Pion/cxx/bool_set/bool_set_N2046.pdf
>
>Some sample code can also be found here :
>http://www-sop.inria.fr/geometrica/team/Sylvain.Pion/cxx/
>
>
>We plan to release an updated interval proposal at some point
>(as soon as possible...).  And we are currently reading through
>the cset documents.

Hello,

I've made this point on the list before, but it might be
worth mentioning in the discussion of tradeoffs in N2046.

Under the rationale:

>It is primarily used for the result of uncertain comparisons of
>types where comparisons can return a trivalent state (e.g.,
>intervals can be compared or overlap), to avoid systematically
>throwing an exception when the comparison returns a result other
>than true or false.

>In this way, bool_set can be used wherever a bool is used and the
>user can expect the same result except if an exception is raised,
>which she then has to handle.

>The benefits are that the code will not compile when bool is
>changed into bool_set and will trigger a code review. The problem is
>that it may not be possible for the programmer to modify the code if
>it belongs to a library

This mostly covers the tradeoffs involved in choosing an implicit
conversion to bool. However, I would suggest also considering a
discussion of std::set<interval>.

In this case, if interval defines

  bool_set interval::operator<(interval&, interval&)

and bool_set offers an implicit conversion to bool, set<interval>
will compile without error and have an unhandled exception if any of
the intervals overlap. The combination of an automatic conversion to
bool while using bool_set with libraries unaware of the tri-valued
logic is at odds with the desire to avoid systematically throwing an
exception when the comparison returns a result other than true or false.

Here the problem is that set wasn't designed to consider that operator<
might throw an exception, the programmer can't modify the library code
to handle the exception, and it is not useful for the programmer using
set<> to handle the exception outside of set. Of course, you can invoke
set<interval, user_supplied_ordering> with some other comparison
which doesn't throw if you are aware of the risk. The convenience of an
automatic conversion creates runtime errors that would otherwise be caught
at compile time in this case.

- Ron Avitzur