Re: [boost] Report from Mont Tremblant C++ Committee meeting

From: Sam Partington (sam.partington_at_[hidden])
Date: 2005-10-18 07:23:29

Hi there,

Firstly whilst reviewing this thread and the optional docs I spotted a
couple of minor typos :

"(Re)binds thee wrapped reference." : thee -> the
"untitialized" -> uninitialized

In the In-place factory discussion, the last code segment has been
corrupted slightly : template<class inplacefactory=""></class>

should presumably be :

template&lt;class InPlaceFactory&gt;

Also, whilst the docs I think in general are good, I find some of the
acronyms used in the docs slightly too informal for formal
documentation, for instance IMO and w.r.t..  Whilst they are well
known, it does cause the brain to stall momentarily whilst trying to
understand some quite difficult concepts.

Now, onto the discussion at hand.

I must admit I find the whole rebinding interface very ambiguous. 
What we have is a reference that is potentially null.  In my mind that
is a pointer (wrapped up obviously), and not an optional at all.  I
use a class called ref_ptr<> for that purpose, and it has served me
well - A smart pointer with no ownership.

That this discussion is going on so long and is so disputed it seems
to me that there is no right-way, and the best way of fixing it is to
disallow T& altogether.

But if it were to stay I would say that the rebinding is very
surpising for someone used to using references.  Take [1] :

int a = 13;
int &b = a;
int c = 42;
optional< int & > d = b;
d = c;

I just showed the above example to someone else at work. Neither of us
have used optional, but have read the docs.  We both assumed that a
would take on the value of 42, certainly I wouldn't expect it to
rebind.

In the rationale the first example states "If you assign to an
uninitialized optional<T&> the effect is to bind (for the first time)
to the object. Clearly, there is no other choice".

Actually there is another choice here - Undefined Behaviour.  If the
following is undefined :

optional< int & >  o;
f(*o);

Then it seems perfectly natural to me that this should be undefined as well :

int i = 0;
optional< int & >  o;
o = i;

Perhaps the problem is the lack of any clue to a dereference on the
lhs, in which case make it mandatory for all types.  Its quite obvious
that this will be undefined :

int i = 0;
optional< int & >  o;
*o = i;

Remove the operator(const T&) and the ambiguity goes away, you either have

int i = 0;
optional< int & >  o(i);
int n = 0;
*o = i;                        // assigns new value
o = optional<int&>(i);  // rebinds, nice and explicitly

Which is what I would expect whether I knew anything about optional or not.

Just my tuppence.

Sam

[1] http://lists.boost.org/Archives/boost/2005/10/95487.php