[std-interval] Interval comparison operators

[Sylvain Pion]

I just read the thread.  Let me add a couple of comments.

First, concerning the "tribool", or "three-valued boolean logic":
since we have empty intervals, I think it is more sensible to
introduce a type which allows to store 4 values.  I was thinking
about naming it "bool_set", whose 4 possible values would have
been: {}, {true}, {false} and {true, false}.  With the operators &,
| and ^ defined on it (with semantics compatible with the inclusion
property of intervals), and mixed operations with bool, as well
as the certainly() and possibly() functions that Guillaume described.
I am unsure about the (throwing) conversion to bool, but it's appealing.
I think such a class can have its place in the standard library,
even independently from the interval class.

Concerning expression-templates.
I think I would prefer to have the compiler know the invariant
of interval<> and perform the optimizations based on that,
rather than adding more complexity in the standard for very
little gain here.
Moreover, thanks to my second remark below, users can also
provide such "expression-templates" comparison operators
if they wish the last bit of speed if the compiler does not
provide it.

Another note concerning the conversion to bool: currently the
language provides "implicit" conversion operators, and no
"explicit" ones.  But there is a proposal to add explicit
conversion operators, and it received good support in Berlin,
IIRC.  So this might be another option.  My next remark
should make this issue less important I hope.


Second, when I presented the interval comparisons in Dagstuhl,
a few people were surprised (to say the least...) about the
fact that they existed, and the choice of semantics.  What this
shows is that it is going to be hard to have a one-fits-all
solution.  We can choose to not offer anything, but I think
it would be nicer to provide something convenient if we can.
The argument of playing nicely with template code has been
raised by Guillaume and Fernando.  Let me add that we can
also anticipate that template code will in the future be
severely impacted by the new concepts and concept_maps (*).
In our case, it means that the semantic of operator< could
be chosen thanks to such a concept_map, and need not be
universal.
So, a soft solution could be to provide various sets of
comparison operators: a "certainly", a "possibly", and a
"returning bool_set" ones.  These 3 sets being defined
inside some namespaces like std::possibly, std::certainly
and std::???.
This way, template code can use concepts_maps, and non-template
code can use "using namespace" directives to choose the
set of comparison operators it prefers.  And code which
does nothing of this kind will simply fail to compile
inadvertant calls to "<" (and people who like the low
level comparisons between interval bounds should be happy).


-- 
Sylvain

(*) Concepts: there are some proposals floating around for
introducing this new feature in the language.  I heard in Berlin
that good progress had been made and that an updated proposal will
soon be available together with a first implementation based on GCC.

Note that the standard committee is currently debating whether
library proposals should depend on new language features or not.
My point of view is that we should anticipate positively concerning
the concepts, and I think we can offer something nice which
does not depend on it, but which will benefit a lot when/if it
will be added to the language.

One of the key feature is that, when a function is parameterized
by a concept (= list of requirements), the mapping between the
requirement list and the type you instantiate the function with,
can be specified via a concept_map, which allows to "redefine"
functions.