Re: [boost] [optional] Breaking changes in 1.33.0 vs 1.32.0

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2005-10-11 15:51:19

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:

>> I have some code that has been merrily using the 1.32.0 release of
>> boost, including boost::optional, and I've just tried to change to
>> use the 1.33.0 release (this is the first change to this codebase
>> since 1.33.0 was released).
>>
>> In my code, I have boost::optional<X> where X is copy-constructible,
>> but not assignable. This works in 1.32.0, but fails in 1.33.0. Ouch!
>
> Oh boy.

struct X
{
    const int a;

    X(int a_):
        a(a_)
    {}

    X(const X& other):
        a(other.a)
    {}
};

is an example of a type with this property.

>>
>> What is the reason for the change?
>
> I need to dig up the archives to recall the exact reason... I do remeber 
> though that there was a good one.
> As for the _justification_ for a breaking change, the idea was that if X is 
> non-assignable,
> then optional<X> should not be assignable either, or at the very least, you 
> don't need it to be assignable.
> That is, you can always write:
>
> optional<X> o ;
> o = none ;
> o = v;
>
> instead of just
>
> o = v ;
>
> if X is non-assignable.

Except that doesn't work in my case, since X doesn't have a valid operator=,
so the assignment fails to compile.

> Anyway, don't you agree that optional<X>::operator= should go through 
> X::operator=? And in that case, is there a choice but to have optional 
> assignment fail with non-assignable types?

I'm not sure I agree that optional<X>::operator= should use X::operator=, but
I can see the logic. Given that, you have no choice but for assignment to fail
to compile if X doesn't have an operator=, unless you can have a trait
somewhere that means the code that uses X::operator= is not compiled for
classes that don't have an operator=.

> Anyway, does the "reset it first" trick work for you? Do you think this 
> change has to be rolled back (just asking)?

Looking at the code for optional, everything is built on top of assignment ---
reset uses assign, for example. This needs to be rethought before it is at all
usable with my code (even if I explicitly use reset rather than assignment).

As a workaround, I could write an operator= that throws, but it's a bit of a
nasty hack.

Anthony
-- 
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk