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]>
> On 4 September 2011 00:14, Mostafa <mostafa_working_away_at_[hidden]>
>> 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
>> 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk