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
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
I do agree that if there's a get(), it should return by reference.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk