[boost] Boost implementation of the Library TR?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-04-30 07:25:55

The acceptance of numerous Boost libraries into the C++ committee's Library 
Technical Report (TR) raises a bunch of "where does Boost go from here?" 
questions. My tentative answers, based partially on private discussion with 
Gregor, Joel de Guzman, Jaakko Jarvi, and others, is given for each 
question.

* Should Boost implement the library TR?

   Yes, although each library developer needs to make sure that makes
   sense for their library, and they are willing to do the work.

* Should we include components not originating from Boost?

   Yes, although that depends on developers willing to contribute
   implementations.

* Including the components originating from the C library?

   No, in general, because the compiler suppliers will in general
   supply those components. Where the lack of a C component is a
   hindrance, we might supply a Boost version as we have done for
   a few standard library headers.

* Do TR components need a formal review?

   Some kind of review is needed to ensure quality, but the process
   should be simplified compared to a normal formal review. Details
   need to be worked out.

* Should we track TR changes made by the committee?

   Yes. The rationale for providing a TR implementation is to (1) make
   the TR available for compilers not yet delivering their own version,
   and (2) providing a reality check on the committee's TR specifications.
   Both of those require a Boost implementation track committee changes.

* Should our TR implementation permit extensions?

   No, unless they can be turned off.

* What namespace should the Boost version go in?

   ("tr1" is "t", "r", followed by numeral one, and is the committee's
   tentative choice for a sub-namespace.)

   std::tr1   // well, this IS an implementation of the standard TR
   boost::tr1 // users can pick and choose, also more traditional

* What header naming convention?

   ???? Note that users can pick and choose an implementation by header
   choice, even if we use namespace std::tr1.

* What if the committee changes the namespace?

   Hum... That could happen. Maybe we should use a macro to make it easy
   to change.

* What happens when a compiler vendor starts to supply TR components?

   We might want to develop some guidelines for users, particularly if
   we don't use namespace std::tr1.

   It might be very useful to be able to run the Boost tests against
   vendor supplied TR implementations. That could help the industry
   achieve compliance faster, and would turn up differences in 
interpretation
   of the specification.

* Should we continue to maintain the pre-TR Boost versions of the 
libraries?

   Decide this on a library by library basis????  Long term, probably don't
   want to continue as we don't want to compete against the standard 
itself.

Comments?

--Beman