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-01 08:51:22

On Wed, 31 Aug 2011 09:41:58 -0700, Fernando Cacciola  
<fernando.cacciola_at_[hidden]> wrote:

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

Just to clarify, I'm not arguing for or from a certain position, rather,  
I'm looking for enlightenment as to what the consequences of disallowing  
the assignment operator for optional<T&> are.

I would be greatly disappointed if you did not follow up to any of my  
direct queries to you, even if it is just a pointer to look elsewhere.

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

Ok, I think I understand your argument.  To clarify, by consistency here  
you mean consistency of programming in a generic environment, so that, as  
you say, a generic library would not have to discriminate between T and T&.

Disclaimer1: What I will say below may have already been discussed, if so,  
please feel free to tell me to google it.
Disclaimer2: I have very little experience with writing generic libraries  
in the C++ sense.
Disclaimer3: Besides the documentation, I have no experience in actually  
using optional.

What are the consequences of doing away with the assignment operator  
totally, and just having a no-parameter reset method that resets  
optional<...> state to uninitialized?

In my naive point-of-view, the majority of Boost.Optional use case would  
involve member-variable types, or interface level types, ie, parameter  
types and return types.  Racking my brain, I can't think of a draw back  
with respect to this use case if the above thought experiment were carried  
out.

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

To clarify, in explaining my motivation for the intent of this thread I  
was saying that a casual programmer would expect that the assignment  
semantics of T would be a subset of the assignment semantics of  
optional<T>, not the other way around.

In general, for any wrapper type class "wrap" and wrapped type T, I think  
that a casual programmer would expect the semantics of the "natural  
operations" of T to be a subset of the semantics of the those same  
operations wherever defined on wrap.  The reasoning being that the casual  
user of wrap who is accustomed to the conventions of T will not be unduly  
surprised when he/she applies those same conventions to wrap.  And in this  
sense, there is no inconsistency between T and wrap, since the "natural  
operations" of T just seem to work with wrap, whenever wrap truly  
represents its underlying type.

But, this is tangential to the intent of this thread.

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

Fair, I understand not wanting to sound like a broken tape recorder.   
IMHO, this indicates a need to add a general "Design Rationale" section to  
the documentation, maybe incorporating summaries of the discussions that  
you allude to.

Thanks for your enlightening response,

Mostafa