Re: [boost] [optional] generates unnessesary code for trivial types

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2012-02-09 08:39:55

> I have a question though. Why prohibit opt = opt assignment? It looks
> quite safe and has a fairly obvious behavior. If I have an optional
> reference as a member of my class, the lack of assignment in optional
> would force me to define a custom assignment operator for my class.
> This seems to be an unnecessary requirement. Also, in the source code
> I dealt with I often saw people writing something like opt =
> optional<T>() to clear the value. This would break with references for
> no apparent reason.

First, let me show why opt = nval; is controversial. Current semantics for
boost::optional<T&> is to rebind on assignment, which means that in the
following code:

  int i = 1;
  int j = 2;
  optional<int&> oi = i;
  oi = j;

The effect of this program is that i remains 1, j remains 2 and oi holds a
reference to j. This is surprising to those that think of optional as
delayed initialization. I lean towards disabling opt = opt because it is
very similar to opt = nval;

  int i = 1;
  int j = 2;
  optional<int&> oi = i;
  optional<int&> oj = j;
  i = j;

The effect here is that i remains 1, j remains 2 and oi and oj both hold a
reference to j. You may find it less surprising but if you think of
optional reference as a regular reference that is initialized a bit later,
the behavior is not what you would expect.

Note that if you store a normal reference to int as class member, you
already have to write your assignment yourself. changing a normal reference
to an optional reference should not come as something irregular.