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

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-02-09 09:05:30

On Thu, Feb 9, 2012 at 5:39 PM, Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
>
> First, let me show why opt = nval; is controversial.

I understand and agree that opt = nval may be ambiguous and even dangerous.

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

I see your point but, IMHO, optional<T&> is too different from normal
references to attempt to draw this association. After all,
optional<T&> is an object in the sense it has internal state and you
can take its address while T& is not (one may call it an alias of an
object). It is therefore logical that optional<T&>::operator= operates
on the object (i.e. on the optional contents) and hypothetical
T&::operator= operates on the referred object.

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

Again, I tend to see optional<T&> as an object, with no apparent
reason why it cannot be assigned to.