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

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

--On Tuesday, September 02, 2003 10:48 PM -0300 Fernando Cacciola 
<fcacciola_at_[hidden]> 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