[boost] Re: generic uses of optional<T>

From: Dave Gomboc (dave_at_[hidden])
Date: 2003-09-01 01:13:11

> [Dave Abrahans]
> Optional is a container.  I've never seen a container in C++ which didn't
> have both a value interface and an element-access interface.  How do
> you propose to achieve that with optional?

It darn well shouldn't be a container, it should be a concrete type! ;-)

> [Joel de Guzman]
> One can think of an optional<T> as conceptually a specialized but 
> nevertheless, *IS-A* T,  with the added specialization that it can
> be in a dead-uninitialized state. Maybe we'll call it a zombie object,
> undead object, you name it ;-)

Indeed.  However, I suppose I actually have it backwards, because I'm so
used to thinking about T.  We know that the set of states T can take is a
proper subset of the set of states nilable<T> can take.  This means that
when we want to write generic code it is sufficient to support nilable<T>:
with an implicit conversion from T to nilable<T>, support for T directly
will come along for free.  (Or is it not possible to create such an
implicit conversion?)

I've been trying to set things up so that code is written for T that can
then also use nilable<T> seamlessly, but doing things the other way around
might be an improvement.

> [Brian McNamara]
> I was originally arguing with Joel because I thought he wanted to use
> exactly "nv" and not anything like "nv.get()".  I think now that we've
> cleared up the confusion about get() returning a reference instead of a
> pointer, we're all back on the same page.

Well, I guess you're still arguing with me ;-) because I _do_ want to use
exactly "nv" and not anything like "nv.get()".  I don't like get() because
I cannot write x.get() when x is a POD.  This would mean I have to support
nilable<T> and T with different code, which is exactly what I'm trying to
avoid.

I do agree that if there's a get(), it should return by reference.

Dave