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

Subject: Re: [boost] [optional] Thoughts on disallowing assignment for wrapped references.
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2011-08-31 12:41:58

Hi Mostafa,

Let me start by warning that this discussion is likely to wind up in an endless 
argument, and I might not have the time to follow up. In any case, if you google 
for it you should be able to find the really long discussions that led to the 
current choice.

 From the 3 possible choices, each one favors certain aspects at a certain 
expense, so no choice is a sensible winner, yet one has to be made, and so I did.

A lot of people is concerned with the current semantics. And a lot of people was 
concerned with the old semantics (it used to assign the referee). In fact, the 
main reason (if not the only one) why Boost.Optional did not make it into Cpp0x 
is precisely the concerns about choice of assignment semantics for references.

The problem with disabling assignment all toghether is basically the same as 
assigning the referee instead of the wrapper: it breaks consistency.

In a highly generic context, which is so typical in modern C++, the T in 
optional<T> might very well be itself a reference type, so any special behavior 
might result in an practical shotcomming, even possibly a show stopper: it could 
simply rule out optional<> as an element of a generic library.

To be a little more precise:

A library that uses optional<T> such that the choice of T is entirely external 
to the library *requires* that optional<> is completely consistent regardless of 
T. If it where to behave specially in the case T is a reference type (or for 
that matter, a non-POD type, a compound type, or whatever) then the library 
itself would have to explicitely handle all such differences.
Recall that in a generic context, the typename T could very well be a reference 
type even without the &, so any time you consider what optional<T&> should do, 
substitute that for optional<U> and think again.

The current choice is to favor consistency for the sake of generic libraries, 
where the library itself would not discriminate whether T happens to be a 
reference type or not.

Keep in mind that

*Assignment to optional<T> is simply not the same as assignment to a T*.

It cannot possibly be for the simple fact that you cannot assign to nothing. 
Hence, optional<> itself must define *its own* assignment semantics, so the 
argument that it should follow the assignment semantics of the underlying T is 
not that strong because it clearly cannot do that on all cases (when the lvalue 
is empty). It is a sensible argument of course, but it must be weighted against 
the equally sensible counter argument that it breaks consistency.

In my balance, consistency wins because it has a direct practical importance: 
without it, certain uses of optional<> would just not be possible.

Best

P.S.: Please do not just counter argument my counter arguments without having 
first googled, read and processed this very same discussion in the past.

-- 
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com