> From: David Abrahams <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > List-Help: <mailto:[EMAIL PROTECTED]?subject=help> > List-Archive: <http://lists.boost.org/MailArchives/boost> > List-Unsubscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>, > <mailto:[EMAIL PROTECTED]?subject=unsubscribe> > List-Subscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>, > <mailto:[EMAIL PROTECTED]?subject=subscribe> > List-Post: <mailto:[EMAIL PROTECTED]> > List-Id: Boost mailing list <boost.lists.boost.org> > Sender: [EMAIL PROTECTED] > > "William E. Kempf" <[EMAIL PROTECTED]> 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. 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); (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 [EMAIL PROTECTED] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
