Re: [boost] Re: Re: Formal review: Optional library

From: Tanton Gibbs (thgibbs_at_[hidden])
Date: 2002-12-13 18:37:44

> Thanks to the clear arguments made by the reviewers, I see the picture a
lot
> more clear now.
> Specially the fact that optional<> is itself a container, or perhaps, a
> union of T and nil_t.
> But your previous post were you developed those concepts were very helpful
> as an argument to keep the pointer-like interface.

I hope you mean "instead of the container interface."

I don't have a problem with the pointer-like interface, it makes sense to
me...I prefer the value
based one, but I understand that is just personal preference.  However, I
definately don't
think we need to mix the two as that would just be confusing.

For what its worth, I prefer the union concept.  Union semantics clearly
state that
you can have either or (i.e., not both).  Furthermore, the fact that Joel
identified
optional<> as a specialization of variant<> reinforces my belief that a
union based
concept would be easier to explain.  When you start explaining this in terms
of pointers
people immediately start assuming memory management and aliasing; however,
optional<>
is not about those.  optional<> in my opinion is clearly a union of T and
nil_t.  Furthermore,
the fact that people have, in the past, used pointers for optional values
does not necesarrily mean
that is the right vision to propogate.  Pointers were the easiest way of
providing an optional value;
it's not that they were comprehensible, or even that they made a great
mental model, just that they were
convienient.  You have a chance now to redesign our notion of what
constitutes an optional value--to
make it comprehensible and convienient.  Holding on to history for history's
sake is not always the best
option.

Tanton