[boost] Re: Re: Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-17 17:15:36

"Rob Stewart" <stewart_at_[hidden]> wrote in message
news:200212172146.gBHLkv719155_at_entwistle.systems.susq.com...
> > From: David Abrahams <dave_at_[hidden]>
> > Date: Sun, 15 Dec 2002 10:29:23 -0500
> > Content-Type: text/plain; charset=us-ascii
> > X-Mailman-Version: 2.1b3
> > Reply-To: Boost mailing list <boost_at_[hidden]>
> > List-Help: <mailto:boost-request_at_[hidden]?subject=help>
> > List-Archive: <http://lists.boost.org/MailArchives/boost>
> > List-Unsubscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>,
> > <mailto:boost-request_at_[hidden]?subject=unsubscribe>
> > List-Subscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>,
> > <mailto:boost-request_at_[hidden]?subject=subscribe>
> > List-Post: <mailto:boost_at_[hidden]>
> > List-Id: Boost mailing list <boost.lists.boost.org>
> > Sender: boost-bounces_at_[hidden]
> >
> > "William E. Kempf" <wekempf_at_[hidden]> writes:
> >
> > > Fernando Cacciola said:
> > >
> > >> However, and very unfortunately, this _requires_ the properly well
> > >> defined relational operators to be disallowed, because they can
> > >> effectively create practical problems if optional is mistaken for a
> > >> pointer and used, for example, to test for aliased equivalence as you
do
> > >> when you compare pointers.
> > >
> > > So, just to keep pointer-like operations you're going to make the
> > > interface difficult to use for many valid use cases?
> >
> > My feeling, FWIW, is that usefulness should trump mis-usability in
> > this case.  I'd rather see deep relational operators and a
> > pointer-like interface, than to see one or the other sacrificed just
> > because we think it might confuse people.  The arguments for each of
> > these interfaces has been made with sufficient force here to convince
> > me that we should keep them.
>
> I certainly find Fernando's argumentation in favor of operator
> *() and operator ->() compelling.  The pointer interface
> certainly models well what optional is doing.  Indeed, I consider
> optional's primary value to be its handling of the case that a
> value might not be available.
>
> I can see some value in using deep relops with optionals, since
> that means a simple expression can handle the optional aspect and
> do the same comparison on the underlying values if present.
> However, one can argue that that is operator abuse.  There are
> those that find operator overloading too confusing, so optional
> will certainly be an example for them if you keep the deep
> relops.
>
> I don't find deep relops compelling.  An optional isn't a value.
> Any code that would use it like a value is wrong, unless it is in
> a restricted context in which the value is known to be
> available. I think the superior interface requires one to
> "dereference" the optional before making comparisons as it
> eliminates a class of errors without making things much more
> verbose.
>
Well, I more or less feel the same about deep relops, but I am convinced now
that there are those who would really like to have them, so the last
version, which I attahed in my last post yesterday,  includes deep relops.

> However, I would be in favor of a functional comparison
> approach.  How about this:
>
> template <typename T>
> int compare(
>    optional<T> const & lhs_i, optional<T> const & rhs_i);
>
Sort of this is provided in the last version, as 'equal_pointees()'.

BTW: This last version can be found as a _different_ zip:

http://groups.yahoo.com/group/boost/files/optional2.zip

--
Fernando Cacciola
> (It can be a mf, too.)
>
> This function can have the deep relop behavior Peter has
> outlined, whereas optional could support either no relops or
> those using state comparison semantics only.
>
>
> --
> Rob Stewart                           stewart_at_[hidden]
> Software Engineer                     http://www.sig.com
> Susquehanna International Group, LLP  using std::disclaimer;
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>