Re: [boost] [optional] New RC_1_34_0 regression

From: Richard Smith (richard_at_[hidden])
Date: 2007-04-04 06:09:26

Vladimir Prus wrote:

> Richard Smith wrote:
> > I know that it's late in the day for fixes on the 1.34
> > branch, but this is silent change in behaviour in a fairly
> > straightforward usage of a commonly used boost library.  I
> > really do think it needs to be fixed before 1.34 can be
> > released.
>
> I disagree. There's no way we can release anything this
> century if we keep on checking in things are branch is
> frozen.  The time window for commits is over at this point.
> If this patch breaks one of release compilers, we'll spend
> another week just to get back to zero regressions.

I understand the sentiment --- it has been a *long* time in
getting to this point, and like everyone else I want to see
1.34 released as soon as possible.  But I don't agree that
this should prevent us from fixing this bug.

My proposed patch is basically a reversion of those headers
to their state prior to the Thu Mar 1 23:08:33 2007 UTC
commit by Fernando Cacciola, but with Steven Watanabe's
attempt to fix their known problem with precompiled headers.

In their old state (i.e. before Mar 1st), <boost/none.hpp>
caused compiler errors when used in precompiled headers in
two popular compilers.  And there was a workaround (don't
use them in precompiled headers).  In their current state,
any standards compliant compiler will preferentially convert
boost::none to int rather than boost::optional.  (I believe
all support compilers do this.)  This is a silent change
that will affect existing code -- I know it does, because
I've found several affected uses in my own code.

I would much rather see a release with this one header
causing compiler errors when used in precompiled headers,
than with a silent change in meaning to wellformed code.
At least a user is forced to acknowledge a compiler error --
a silent change in meaning relies on the end users' unit
tests noticing it.

The fact that only the former error is caught by the
testsuite doesn't, in my opinion, mean the latter is any
less of a regression -- rather it's a deficiency in the
currrent testsuite.

> The final decision is up to Thomas, of course, but I hope
> that no code changes will be allowed, no matter what.

In that case, I think we disagree.

Richard Smith