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 09:33:03

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

I understand (I think) your point of view. Let me clarify one thing. I am
thinking of disabling the assignment not because I think it does not belong
to references, but because there are two ways of implementing it, and
implementing it either way would surprise a different group of programmers.
And this would be a "run-time surprise". Instead my choice (not necessarily
the best one) is to provide a "compile-time surprise".
With your view of optional reference (if I got it right it is a pointer
with a somewhat different syntax) your expectation of rebinding assignment
comes as natural. With a different model of optional reference a
non-rebinding assignment comes as more natural. I believe that
optional<reference_wrapper<T>> would serve your purpose best. Or would it
also introduce the lack of uniformity?