On Wed, 31 Aug 2011 22:13:30 -0700, Nevin Liber <nevin@eviloverlord.com> wrote:
On 31 August 2011 16:13, Mostafa <mostafa_working_away@yahoo.com> wrote:
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.
I still contend that your mental model is wrong with respect to C++ references (but understandably so, as I'll get to).
Let's start with local objects. Take:
{ Foo f; // f exists //... } // f will shortly get destroyed
The lifetime of f is from when it is done being constructed until a little after its enclosing scope is destroyed (at which time objects are destroyed in reverse order of creation). Within that stack frame, f exists exactly 1 time; no more, no less.
Now look at member variables:
struct Bar { Foo f; };
The lifetime of Bar::f is from when it Bar::f is constructed until shortly after the Bar object is destroyed. Within any instance of Bar, f exists exactly 1 time; no more, no less.
I'll call the above two examples the normal lifetime window. If you pair up new/delete, I can define a similar window for heap based objects as well, but by now you get the idea.
Moving on to boost::optional for objects:
{ boost::optional<Foo> maybef; // ... }
Within the normal lifetime window, the object maybef holds can exist 0 or more times. Those are the semantics boost::optional gives us.
Moving on to C++ references:
{ Foo& reff /* what goes here depends on if it is a local or class member... */; // ... }
Within the normal lifetime window, the reff is bound to an object exactly 1 time; no more, no less.
Given that, within the normal lifetime window, what would you expect to happen for an optional reference:
{ boost::optional<Foo&> maybereff; // ... }
I see the same thing as all of the other cases, the "exactly 1 time" is relaxed into "0 or more times".
Ahh, I disagree with that. IMO, if maybereff was not bound at construction time, then it should always remain "uninitialized". That's another reason why I wanted to explore the implications of disallowing the assignment operator for optional<T&>. Now Fernando has made an interesting case for why disallowing the assignment operator for optional<T&> and allowing it for all other types is bad. I will be responding to Fernando with some more question(s). I would also be interested in knowing your answers to those question(s). Mostafa