[boost] Re: Boost implementation of the Library TR?

From: David Abrahams (dave_at_[hidden])
Date: 2003-05-02 08:23:12

Beman Dawes <bdawes_at_[hidden]> writes:

> What is your opinion on the other issues?
>
> --Beman
>
> * 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.

I'm not sure.  There's at least one TR library which isn't a boost
library, right?

> * Should we include components not originating from Boost?
>
>     Yes, although that depends on developers willing to contribute
>     implementations.

What does this mean?  Lots of boost libraries originated on someone's
machine at home.

> * Including the components originating from the C library?
>
>     No, in general, because the compiler suppliers will usually
>     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.

So, "maybe"

> * 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. 

Why?  Presumably the specification will be even more rigorous than
what we have at Boost, since there will have been more eyes on it.  I
think we ought to consider going the other way.

> * 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.

If possible, yes.

> * Should our TR implementation permit extensions?
>
>     No, unless they can be turned off.

OK.

> * 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

user-configurable

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

Same as the standard, plus .hpp.

> * 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.

We certainly have extensions we'll want to maintain.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com