Re: [boost] [optional] rebinding references

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-10-24 12:42:58

Rob Stewart wrote:
> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
>> David Abrahams wrote:
>>> Anthony Williams <anthony_w.geo_at_[hidden]> writes:
>>>
>> Antony's proposal goes even beyond Sam's idea: rather than dropping
>> assignment from T, we spell it: reset().
>> That is definetly better then direct assignment from T, but I'm not
>> quite sure that is as good a solution as keeping just copy
>> assignment.
>>
>> Consider these 3 versions:
>>
>> int a = 1;
>> int b = 2;
>> int& ra = a ;
>> int& rb = b ;
>>
>> optional<int&> o(ra);
>>
>> *o = rb ; // Clearly doesn't rebind but is UB if 'o' were null.
>>
>> // (1) Current case:
>> o = rb ; // rebind or not??
>>
>> // (2) Antonty's proposal:
>> o.reset(rb); // still some room for doubts?
>
> That is better because one needs to know its behavior; it's a bit
> harder to assume you know what reset() does than what assignment
> does.
>
> Your concern that using reset() makes optional look that much
> more like a smart pointer, belying the difference in deep versus
> shallow copying isn't as significant as you make it out to be.
> Not all smart pointers do deep copies and yet reset() is a
> sensible name.  Thus, I think reset() is a reasonable name,
> precisely because optional is so much like a smart pointer.
>
> OTOH, I suggest that reset() take no arguments and only be a
> (the?) way to "unbind" the optional.  IOW, rebinding should be
> spelled differently.
>
So you'd prefer:

o.reset()

to

o = none

?

Well, I guess that's depend on what with do with assigment.

If there's only copy assignment, 'o = none' looks consistent.
If there is rebind(), reset() looks consistent.

> As mentioned elsewhere, this won't understand how to deal with
> references versus non-references correctly.  You need the user to
> indicate when a reference should really be a reference in the
> optional.
>
Right, so we need something else.

>> I think (3) spells the actual semantics (rebinding) even more
>> clearly than (2).
>> OTOH, both (2) and (3) are equivalent, so the difference is merely
>> sintatical.
>> Having said that, I prefer (3) which just looks better to my eyes,
>> but (2) could work too.
>
> I think copy construction is quite obvious and removes the
> (non-)reference confusion of make_optional().
>
The only problem I see with copy assignment is that it requires you to spell 
out the wrapped type; that can be a nuisanse.

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