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

Subject: Re: [boost] [optional] Thoughts on disallowing assignment for wrapped references.
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-08-31 19:09:24

On 8/31/2011 5:13 PM, Mostafa wrote:
> 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,

If you want to change the assignment operator for optional when the type 
is a reference, just derive a class template from it, change what you 
want, and use that template to create object types rather than optional.

While you are of course free to have your own opinion on the matter, and 
argue for it, citing that programmers will not be used to the 
functionality, and that they are normally not going to read the 
documentation to understand it and its reason, is not a strong argument.