--On Tuesday, September 02, 2003 10:48 PM -0300 Fernando Cacciola <[EMAIL PROTECTED]> wrote:
[snip]
I hope you come back later... :-)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.
Thanks.
Extactly.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.
Ok, I got it now. Thanks for your patience in explaining your rationale.
[snip]
This will be provided in the next update.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.
Great!
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.
Hmmm. I certainly understand your concern about operators * and-> But I don't see what's wrong with container-like ideas. I bet it is easier to explain that optional<T> is a container that has a T or is empty than that it is a disciminated union of T and nil_t. After all, containers are everyday structures, yey variants are not.
Hmmm. Food for thought. Perhaps I should test out explainability on some potential clients of my code from this viewpoint.
[snip]
This will be supported by the next update.* 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).
Great!
[snip]
* Backdoor to uninitialized storage available, e.g. unsafe_reference()
What do you need this for? (provided direct assignment is supplied)
I thought that I might needed this for tie or output reference parameters to work.
* Works reasonably well with tie()
This will be covered.
Thanks. Still curious as to the details of how optional might work with tie, but perhaps I'm missing something obvious. Anyway, if optional is going to provide this too then you've smoothed over the main difficulties that I found in my initial usage. The existence of the pointer syntax is not troubling enough to me to warrant working on an alternative.
[snip]
Thanks again for considering these matters and taking the time to clarify your rationale. I look forward appreciatively to the planned enhancements.
- Mat _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
