[boost] Re: [optional] new assignmet semantic and references

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-03-08 19:48:10

"David Abrahams" <dave_at_[hidden]> escribió en el mensaje 
news:uy8d2p528.fsf_at_boost-consulting.com...
> "Brock Peabody" <brock.peabody_at_[hidden]> writes:
>
>>> On Behalf Of Fernando Cacciola
>>> Sent: Tuesday, March 01, 2005 10:39 AM
>>> To: boost_at_[hidden]
>>> Subject: [boost] Re: [optional] new assignmet semantic and references
>>
>>>
>>> So I think I will fix it unless users speak up...
>>> Though I will post this issue in the users list as well.
>>
>> First I'd like to say that I love optional<>.  When I first read about it 
>> I
>> didn't think I'd use it much, but now I find myself using it all over the
>> place.  It's useful for so many things, but to me the most important is 
>> how
>> it improves my ability to make code self-documenting.
>>
>> Personally, I like it the way it is.  I've used optional quite a bit and 
>> it
>> makes sense to me that operator= changes what an optional holds.  I don't
>> think it is a good idea to give operator= special semantics for 
>> references.
>
> I had the same feeling.  That's what I meant when I said
>
>  "It depends on whether you view optional<T> as a T that might just
>  happen to be missing, or as a container for a T."
>
> I think "a container for a T" is a more manageable meaning for
> optional<T>.
>

This issue was there from the very beggining...
It sort of reminds me about whether electrons are particles or waves... 
they're both, but not exactly at the same time in the usual sense... it 
depends on how do you _want_ to look at them.
Unfortunately, optional<> is not as smart as electrons in masking themselves 
to the user's convenience.
IMO both views are equally OK.. Each user sees pros in one and cons in the 
other, and there is no cut clear concensus on which one is definitely 
better.

Yet I need to weight the balance one way and I choosen to favor the wrapper 
view... much of the latest evolution goes in this way.

>> I think it odd, for instance, that given the following optionals:
>>
>>     int a = 5, b = 6;
>>
>>     boost::optional<int&> ra = a, rb = b;
>>
>> this:
>>
>>     ra = rb;
>>
>> would have different behavior than:
>>
>>     ra.reset();
>>
>>     ra = rb;
>>
>> I can understand the desire to mimic the semantics of built in C++
>> references in boost::optional, but one uses boost::optional precisely in
>> cases where one does not want those semantics - in cases where a 
>> reference
>> may not be present, and where you may want to change which object is
>> referred too.
>
> This is what I'd have said if I'd had the time to really consider it
> deeply and write it out.  Nice, Brock.
>
Well, I agree that optional<> is intended to give you something you don't 
get straight from the language, but as it is now, its goal is to offer you 
something more of an extension of what you already get than a replacement.

Furthermore, you can get rebinding semantics via optional< ref<T> >.

Best

Fernando Cacciola