> [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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
