On Wed, 31 Aug 2011 09:28:49 -0700, Nevin Liber <nevin@eviloverlord.com> wrote:
On 31 August 2011 04:56, Mostafa <mostafa_working_away@yahoo.com> 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