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-08-31 17:13:27

On Wed, 31 Aug 2011 09:28:49 -0700, Nevin Liber <nevin_at_[hidden]>  
wrote:

> On 31 August 2011 04:56, Mostafa <mostafa_working_away_at_[hidden]> wrote:
>> Let me reword and expand my concerns.  I view boost::optional as a thin
>> wrapper for it's underlying type, with the added sugar that it can  
>> convey
>> whether its instance has or has not been set by the user.  Hence, it  
>> behaves
>> very much like a smart pointer.
>
> In "The models" section of the documentation, it quite clearly states
> (in a highlighted box no less) " optional<> is not, and does not
> model, a pointer."  Your mental model is wrong.
>

I'm quite aware of that.  Unfortunately, the passage in which I was quoted  
was taken quite out of context.  Frankly, I too could have been more  
careful in my wording.  In the context of the my lengthy passage, what I  
was trying to convey is that just as smart pointer is a thin wrapper for  
its underlying type, so too optional is a thin wrapper for its underlying  
type.  Hence, don't think I have the mental model wrong.  (Given that my  
previous post was a little lengthy, maybe a rereading of my previous post  
will help clarify my position.)

> Are they reading *any* documentation?  "Optional references" is
> mentioned more than once (in the table of contents) on the front page
> of the documentation.
>

As I mentioned in my previous post, there is no indication that this  
section points out inconsistent behaviour with regards to bare C++  
references.

It has been my experience that programmers read documentation more  
thoroughly when they're developing, versus when they're maintaining,  
especially if it's other peoples code that they maybe enhancing/fixing.

> I don't know how you solve the problem of people not reading
> documentation, because the number of different mental models that
> people can make up that don't fit the implementation is unbounded.

I agree with you, and that's why, IMHO, implementations should follow  
existing conventions as much as possible.  And that's why I was exploring  
the disallowing of the assignment operator for optional<T&>, because in  
some use cases the behaviour of the assignment operation for optional<T&>  
is inconsistent with an existing convention, namely that of bare C++  
references.

Hopefully this clarifies what I was trying to say,

Mostafa