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

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2003-09-02 20:48:30

Mat Marcus <mmarcus-boost_at_[hidden]> wrote in message news:169794441.1062456261@[192.168.1.103]...
> --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.
>
Well, it isn't noise for me yet.
I'm still finding it useful, at least some of the derivations that are
not directly related to the OptionalPointee special syntax.

> 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... :-)

> 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.

> Additionally, optional deliberately does not require a throw or assert
> upon uninitialized use, preferring to leave this as a QoI issue.
>
Which by the way means that it is you, the user, who decides what to do.
That is, "undefined behaviour" in this context means that optional itsef
doesn't attempt to define it and leave that to the client.
With the current implementation, you define this by supplying a definition
of boost::assertion_failed

> 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.

> 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.

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

>    * Where transparency is not feasable forego pointer-like syntax to
> avoid any appearance of relation to pointers/iterators
>
OK, this won't.

>    * The action upon use while in uninitialized state shall be
> specified or even specifiable (throw/assert/etc.).
>
I've leaven it undefined so it can freely specified

(but without the need of sophisticated protocols)

>    * Backdoor to uninitialized storage available, e.g.
> unsafe_reference()

What do you need this for? (provided direct assignment is supplied)

>    * Works reasonably well with tie()

This will be covered.

>    * No double storage penalty

And this of course is provided now.

> 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.
>

Good.

Dave Gomboc is also working on an alternative,so let's see what comes

out.

Fernando Cacciola