Re: [boost] TR1 conformance?

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2006-12-10 16:15:39

On Dec 9, 2006, at 5:43 PM, Beman Dawes wrote:

> Dinkumware has made a copy of their TR1 test cases available to me,  
> and
> I've been running then on the Boost CVS HEAD and reporting apparent
> failures to Boost library maintainers.
>
> John Maddock ran into some type traits test cases where the apparent
> failure was due to an issue with the TR1 spec itself. John wrote:
>> This all raises the um, interesting question of whether we should
> slavishly
>> follow the TR1 text, or try to correct defects, and/or be ahead of  
>> the curve
>> as Boost traditionally has been.
>
> My answer is "that depends."
>
> If there is a problem with the TR1 specification, we should implement
> what we think is correct, and file a defect report with the C++  
> committee.
>
> If we have figured out a better way to do something, we should go  
> ahead
> and implement the better way, and file a defect report with the C++
> committee so that the C++0x version of the library can take  
> advantage of
> the improvement. Should the deviation from TR1 be under macro control?
> Is this just QOI left up to the implementer?
>
> But otherwise, we should just follow TR1. The point of having a
> Technical Report is that implementers all follow the same script.
>
> Comments? Opinions?

I think it would be counter productive for boost to implement a  
clearly flawed spec, whether that spec be a TR or even a standard.   
There are places in the C++98/03 spec which I just flat refused to  
slavishly follow in the CodeWarrior implementation because I knew  
these ways to be inferior (and I know some other implementations  
which followed this philosophy as well).  As long as I was right,  
customers never complained.  When I was wrong, customers did complain.

Boost should look to its customers for the final spec, not to an  
internal or external document.  When customers disagree, you have to  
find a way to please as many as you can.  Without customers,  
libraries such as boost have no purpose whatsoever.

When boost tr1 implementations differ from tr1 specs, and  
purposefully - for good customer-oriented reasons, boost members  
should complain to the committee (and I just drew a bulls-eye on my  
forehead ;-)).

In the case of the type traits library, for those concerned I  
encourage you to peruse:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html

These are my suggestions for what needs to be changed for the type  
traits library in C++0X.  The paper isn't perfect, and has a couple  
of obvious type-o's.  I'll be writing a revision.  Please send me  
your comments, both positive and negative, so that I can incorporate  
them into the revision.  The first paper failed in committee for lack  
of motivating statements for the changes.  So for positive comments,  
including *why* you like the proposed change (i.e. motivation) would  
be a great help (and thanks in advance).

If the type traits library is important to you, this is your chance  
to get your input into committee on an easy fast track (I'll do the  
grunt work).  Though no guarantees of success are implied here.  I  
have to fight with the committee just like the next guy.

-Howard