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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
