Re: [boost] [optional] rebinding references

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-10-21 14:55:49

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.

> // (3) Sam's proposal:
> o = make_optional(rb); // Clearly rebinds, doesn't it?
> 
> // I just introduced make_optional() here to get rid of the template 
> argument

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.

> 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().

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;