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-09-05 17:24:08

Hi Mostafa,
> 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.
>
OK.
If you consider doing that with boost::optional<>, then the biggest consequence 
is that is changes the current behaviour. So let's consider the case of an 
alternative class.

> 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.
>
Well, don't be.
I work 12 hours a days (seriously), and have a wife and two kids on top of that, 
so often I cannot even read this group.
If I dissapear it won't mean that I'm not interested in responding, just that I 
simply can't.

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

> 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

The consequence is, well, that you cannot assign to it :P

Granted, you can get away without assignment to a certain extent, and we might 
agree that doing so is often a good thing, even in C++ which is not a pure 
functional language. But, since C++ purposedly supports and embraces other 
programming paradigms as well, removing assignment alltoghether might not be 
feaseble, or practical, and in many cases, not even desirable. In the design 
space that is most natural to C++, assignment is a fundamental operation.

boost::optional<> is an utility which is specifically designed to be general 
purpose, and to that effect it must support a wide range of applications.

Doing what you propose will simply reduce, and quite significantly, the 
usability of it.

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

He would expect that, yes. And he would be surprised. And there is an 
incosistency in the terms you are stating it.

However, the behvaiour a library component cannot be based solely, nor even 
primarily, on what a causal programmer would expect, or what would be suprising. 
Those are elements to take into consideration.

Sometimes, subtelty is justified by the benefits. Take std::auto_ptr just to 
name a simple example.

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

That seems like a good idea.

Best

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