Re: [boost] [optional] Thoughts on disallowing assignment for wrapped references.

Subject: Re: [boost] [optional] Thoughts on disallowing assignment for wrapped references.
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2011-09-06 05:52:14

On Sun, 04 Sep 2011 00:56:50 -0700, Nevin Liber <nevin_at_[hidden]>
wrote:

> On 4 September 2011 00:14, Mostafa <mostafa_working_away_at_[hidden]>  
> wrote:
>> That seems to be the consensus so far.  Assuming that I'm creating
>> optional2, so we don't have to worry about existing code, and that it's
>> equivalent to optional in all respects except that the assignment  
>> operator
>> has now been disallowed across the board, and we've only retained a
>> no-argument reset method.  What are the implications of that?
>
> The same problem that references and const variables have; namely, any
> class that has them as members is non-Assignable (both
> non-CopyAssignable and non-MoveAssignable).
>

Ok, that's a valid concern.  I forgot to generalize the implication to the
composing class.

>
> That leaves using your class for local variables or parameters, and I
> don't see much usefulness there either, as a pointer is a far easier
> construct to use for such a localized effect.

I'm going to go off-topic here, but it's going to explain my reasons for  
considering the use of optional.

The problem with using pointers/references to represent the "is  
optional"/"is required" idiom is two-fold:

1) Raw Pointers
Raw pointers don't convey the semantics of their life-time policy, hence  
one has to rely on some convention, which can easily change from project  
to project even within the same company.  Hence the motivation for using  
smart pointers where feasible.

2) Smart Pointers
Smart pointers are nice in that they convey the semantics of their  
life-time, but their have been many discussions on this forum which have  
advised against passing or returning a dereferenced smart pointer by  
reference.  If we were to follow the latter advice, and I am inclined to  
do so, then smart pointers become a noop for the aforementioned idiom.   
And this creates a new problem, in that now smart pointers don't convey  
the semantics of their "optionalness".

Which brings me to Boost.Optional.  Boost.Optional is nice because it  
conveys its intent explicitly, and I can use it directly with smart  
pointers.

Mostafa