Boost logo

Boost :

Subject: Re: [boost] [optional] Thoughts on disallowing assignment for wrapped references.
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2011-09-08 09:10:31

On Wed, 07 Sep 2011 23:44:42 -0700, Nevin Liber <nevin_at_[hidden]>

> On 7 September 2011 23:15, Mostafa <mostafa_working_away_at_[hidden]>
> wrote:
>> 1) Were the assignment operator disallowed for optional<T&> and only
>> optional<T&>, there would no loss of programmatic generality when
>> optional<T&> is used as a local variable.
> I just don't see a use case for when it is a local variable, ... <snip>

In trying to answer "what are the implications of disallowing the
assignment operator for optional<T&>" I had to consider the all possible
use cases of optional<T&>, and they are 1) where optional<T&> is used as a
local variable, and 2) where optional<T&> is used as a member variable.
Well, there are namespace variables too, but it's obvious the implications
are the same as 2).

> The case we've mentioned that you haven't covered is returning it from
> a function,

In what respects haven't I covered it?

> which again, is problematic for two reasons:
> (1) Types that are Copyable but not Assignable are surprising

Not necessarily, think of Pimpl. If I have a Pimpl class heirarchy, then
operator= becomes problematic for the base class, therefore I disallow it
in all cases.

What about using such a Pimpl in stl-like containers? Answer, use the
opaque handle of the Pimpl, and reconstruct the Pimpl from the opaque
handle where necessary.

> (2) It is rare to return a reference anyway, as something outside of
> the callee has to manage the lifetime of the underlying object

Not that rare. Let's say I'm using raw-pointer/reference idiom to convey
the semantics of optionalness, then returning a reference is certainly an
option. I believe it's the callee that has to manage the said lifetime.


Boost list run by bdawes at, gregod at, cpdaniel at, john at