Boost logo

Boost :

From: Mat Marcus (mmarcus-boost_at_[hidden])
Date: 2003-09-01 15:24:45

--On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola
<fernando_cacciola_at_[hidden]> wrote:

> Joel de Guzman <djowel_at_[hidden]> wrote in message
>> 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 ;-)

Hmmm. I'm not so sure about this. When I hear the phrase optional<T>
IS-A T with an added specialization I am reminded of the phrase a
Square IS-A Rectangle with an added specialization which usually gets
folks into trouble. [Theoretical aside: I still see optional<T> as a
sum/union, e.g. T + nil/ T | nil. That is I don't think we really want
A + B < B (the sum/union of A and B) to be a subtype of A.]

> Theoretically, yes.
> But there are practical barriers here.
> Unfortunately, in C++ subclassing is the only subtying mechanism,
> but you can't subclass a non class type, so you can't subtype
> an arbitrary T.
> IOWs,

Enter (syntactic) concepts and models thereof.

> there is no way to completely implement an optional<T> which
> *IS A* T.

As I said above I'm not sure that I would want to.


Here's a question that tries to get to the crux of the pointer-like
interface matter. Should T* and optional<T> both be models of a
pointer-like syntactic concept?

I imagine that those who would answer yes do so because they may want
to write generic code that uniformly handles pointers and possibly
uninitialized variables. Those who answer no to the above question may
prefer to write code that uniformly handles T and optional<T>. As you
know, my (current) answer is no. There may be a third group who want
both. The problem is that I find that the pointer-like interface is
distracting, but that may be because I'm unfamiliar with the use-cases
where you might want to handle T*'s and optional<T>'s uniformly or
even replace raw pointers with optional<T>'s, since pointers also
bring allocation issues with them. Instead I have been mainly focused
on replacing T's with optional<T>'s. This is why I gravitate towards
having an optional that models a syntactic concept such as PU that
makes no mention of pointer-like syntax.

By the way, I would also like to thank you for your work on optional
and your contributions to boost. I also appreciate your open
discussion of the design of optional and optional-like classes. My
posts are just those of a potential user who is interested in finding
the right point in the design space for my needs. If my use cases or
arguments prove useful to others or if optional is influenced to meet
more of my needs, then of course I will be pleased. If not, I'm still
learning about the design space from you and others on this list, so I
benefit either way.


Boost list run by bdawes at, gregod at, cpdaniel at, john at