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

[Mat Marcus]

--On Tuesday, September 02, 2003 10:48 PM -0300 Fernando Cacciola 
<[EMAIL PROTECTED]> wrote:

[snip]


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.
I hope you come back later... :-)
Thanks.


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.
Extactly.
Ok, I got it now. Thanks for your patience in explaining your 
rationale.

[snip]

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.
This will be provided in the next update.
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]

   * 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).
This will be supported by the next update.
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