Boost logo

Boost :

From: Mat Marcus (mmarcus-boost_at_[hidden])
Date: 2003-09-02 00:44:21

--On Monday, September 01, 2003 9:52 PM -0400 Brian McNamara
<lorgon_at_[hidden]> wrote: [snip]

> As a final aside, I think much of this thread is degenerating into
> Parkinson's Bicycle Shed[*], with respect to "is it a
> pointer/container/X?" At this point, I think we know what set of
> methods should be in the interface (indeed, there could be methods
> both to return pointers and references; both to
> throw/fail-undefinedly, etc.) and the names/documentation issues
> will fall out with more experience. Just MO.
> [*] See bottom of

I'm not sure that we are discussing the shed just yet. I think we have
finally identified some of the key design alternatives and their
rationales. But it is true that this thread has received a number of
posts now and I'd hate to think that it is degenerating into noise.
For this reason, and for the fact that I have some upcoming deadlines
at work, I'll summarize what I see and where I stand now, then I'll
step back a bit for a while.

Summary of thoughts on the existing optional:
It now seems to me that the idea of the pointer-like interface wasn't
so much to treat pointers and optionals uniformly. Rather, what I'm
hearing is that the pointer-like interface was chosen because of the
familiar syntax and idioms with regard to checking for initialization.
Additionally, optional deliberately does not require a throw or assert
upon uninitialized use, preferring to leave this as a QoI issue. I can
respect this set of design decisions, and optional in this form
certainly has its uses. If optional<T> grows to allow more transparent
co-existence with T (implicit construction, smooth tie
interoperability) then I expect it will become even more useful.

Summary of thoughts on an alternative to optional:
While optional offers much of what I need, I still have trouble with
the pointer-like interface, largely for reasons of explainability. I
believe that clients/maintainers of the libraries that I write would
be distracted and confused by the a pointer-like interface or
container-like ideas. What I really want is a simple class template
that models Possibly Uninitialized variables with no mention of
pointers at all. Perhaps I'd call it Maybe, or SmartVar.

How would I specify it? Well at a high level my (sloppy, late night)
design goals would include:
   * Interface driven by the desire to replace "dumb variables" with
"smart variables" -- that is variables that check that they've been
initialized before use, offer smooth interoperability with dumb T's
(e.g. assignment and implict operations where sound).
   * Where transparency is not feasable forego pointer-like syntax to
avoid any appearance of relation to pointers/iterators
   * The action upon use while in uninitialized state shall be
specified or even specifiable (throw/assert/etc.).
   * Backdoor to uninitialized storage available, e.g.
   * Works reasonably well with tie()
   * No double storage penalty

Clearly optional is a fine piece of work and satisifies many of these
goals. If it satisified a few more of them then I might find it usable
in my current projects, perhaps completely ignoring the pointer-like
protocol. For now I may work an a small lib that directly addresses
the goals above.

As I mentioned at the start, I've spilled enough words on this so I'll
step back for a bit now. But if others are interested in working
together in this area (on or off list) then perhaps we might
collaborate. Thanks again to Fernando, Joel, Brian, Dave G. and others
for discussing all of this.

 - Mat

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