Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

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.

[snip]

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.

Thanks,
Mat