[std-interval] Portland standardization meeting feedback

[Sylvain Pion]

Dear std-intervallers,

Here are some news from the discussions that just took place at the ISO
C++ (WG21) meeting in Portland, concerning the interval and bool_set
proposals.

The proposals have been discussed by the Library Working Group.
The discussions have not entered much details, because the committee
is very busy, and almost nobody had looked at the details before the
presentation.

The LWG nevertheless ran the following 3 straw polls, which results
are still positive for us.  I guess a more formal vote for inclusion
in TR2 will take place at one of the next meetings.  ( TR2 itself will
probably take a few years to be closed, as work on C++0x has higher
priority. )

                                  ++  +  -  --
Interest in bool_set :            3  5  0  0
bool_set for C++0x (vs TR2) :     0  1  2  4
Interest in interval for TR2 :    2  5  2  1

So both proposals are still supported, targetting TR2 rather than
C++0x.  We're still on track!

[ Notes :
   - C++0x is the code-name for the next standard
     (hopefully published in 2009),
   - TR2 is the name for a technical report which is non-normative,
     but published, and which compiler vendors try to follow.  It serves
     as a place to expose the proposals on a large public scale.
     For example, Boost has an almost complete implementation of TR1,
     and GCC and Dinkumware as well (the standard lib of Visual C++).
]


The only reason raised by those against the proposal is the
implementation difficulty.  One of them would be OK if there was
some non "open-source" (in the sense of "lawyer-frightening")
code available that he could base his code on.
I told him I hoped that IEEE754r will hopefully imply that such
code will be made available at some point through the libC...

Boost people would appreciate if a default implementation would be
made available.  So, one question : is there any volunteer here
to do that ?  Something based on MPFR or CRLIBM or any other open
source code would do it, as long as it follows the specification,
and has the Boost License.  It's pretty important to get support
from them.  It does not have to be top-efficient nor top-precise,
but it has to exist and match the specs.


I did not get much technical questions, only minor things :
- the I/O specification as we did it is the right thing for now,
   but breaks the ABI (it adds a virtual function to a class).
   It is a general problem, and this most probably means it will
   be solved by others, and we will just have to follow.
- some remarks have been raised for the choice of free functions
   versus member functions (by Jeff Garland).  But after discussion,
   I think I convinced him that we do something reasonnable.
- bool_set should most probably not offer the && and || operators.

I'm sure we'll get more questions once people seriously look at
the specifications, but it may not come soon.

I guess that the next task for us is to issue revisions of the
proposals, and then ask for a formal vote for inclusion in the
TR2 working draft.

-- 
Sylvain