Re: [boost] [optional] rebinding references

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-10-18 13:52:55

Joel de Guzman wrote:
> Fernando Cacciola wrote:
>> Rob Stewart wrote:
>>
>>> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
>>>
>>>> I wonder what would be the result of the following thought
>>>> experiment: Please, answer the questions _without_ looking at the
>>>> answers, and if possible post your initial results; then compare
>>>> with the answers.
>>>
>>> IANAOU either (yet!), but I'll give my answers.
>>>
>>> First, I'll describe what I think the right behavior is; this may
>>> be exactly how optional works now or it may not be.  I haven't
>>> compared this description to optional's documentation.
>>>
>>
>> OK. You just described Joel's proposed behaviour, and, from your test
>> results, it's clear that at least you wouldn't be confused about the
>> fact that in one case it binds while in the other it doesn't.
>> Now I wonder how would that be in real code... I mean, in my example
>> you could infer from the context that 'o' was null in one of the
>> cases... but what if you can't tell that? you wouldn't be able from
>> context alone to know the expected effect of assignment. That's real
>> problem don't you agree?
>
> For the record, that is not exactly my proposed behaviour.
> I am objecting to *any* form of bind/rebind *from assignment*.
> Maybe that was not clear (as I noticed from Peter Dimov's
> reply) but what I am advocating is bind only at construction
> time (see my reply to Peter Dimov).

Ha yes, you are right..
You just once mentioned that you could live with rebinding from copy 
assignment at most.

>
> Anyway, I like the new direction this is heading into

Me too! Finally getting somewhere.

> (i.e.
> no assigment from T and the reset(), reset(nil), reset(T)
> syntax).
>
Well, I'm not so sure about reset().
My very first boost submision had reset() and no assignment from T, exactly 
as we are considering now. But the big problem, and it was big, was that it 
just made people be even more confused about optional<> being yet another 
smart pointer (precisey becasue auto_ptr and shared_ptr uses it).

AFAICT, the choice between:

o = make_optional(val);
o = nullptr ;

and

o.reset(val);
o.reset();

is just cosmetical.. and at that, I prefer the first version because it 
pushes optional<> away from a smart_ptr.

IOW, that it uses * and -> just like any other nullable type makes sense 
because the semantics of these operators are the same for all nullable 
types; but the semantics of reset() in the case of optional<> are different 
from those of a smart ptr (deep vs shallow).

Best

-- 
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com/