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

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
>    http://www.boost.org/more/discussion_policy.htm

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.
unsafe_reference()
   * 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