Boost logo

Boost :

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

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

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

Hopefully this clarifies what I was trying to say,


Boost list run by bdawes at, gregod at, cpdaniel at, john at