220 4242 <5f236e41-0f5f-4288-a80f-9eadb5168c38@isocpp.org> article Path: news.gmane.org!not-for-mail From: Marc Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Fixing Standard Library relational operators (was: Re: optional Rev.4 (N3672): What was the rationale to remove !=, >=, ...) Date: Fri, 3 May 2013 10:55:48 -0700 (PDT) Lines: 165 Approved: news@gmane.org Message-ID: <5f236e41-0f5f-4288-a80f-9eadb5168c38@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_59_1628107.1367603748798" X-Trace: ger.gmane.org 1367603754 692 80.91.229.3 (3 May 2013 17:55:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 May 2013 17:55:54 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCGJRE7HX4IBBJ7UR6GAKGQE2TWSMPQ@isocpp.org Fri May 03 19:55:53 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UYKD2-00071m-LN for gclcip-std-proposals@m.gmane.org; Fri, 03 May 2013 19:55:52 +0200 Original-Received: by mail-ie0-f199.google.com with SMTP id s9sf9605165iec.2 for ; Fri, 03 May 2013 10:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:message-id :in-reply-to:references:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=fKsc3gi7iAC+TELRodt4xozL2o4oXmAPn2Y02+FEol0=; b=xMY7xF3pZPZy5gPBk2n0dtugzhlgt54E0p0TadZewV1c3j50qtbj0RgMqpwYmmSIYE aooVjyt5+wnpso7McUwKWiJNdCWKl+WshWnPfgl69JY3Bx188EvYBTaPVLp+b66DBFP9 OyjvZcOXvvYBIaOVuSGxjwCApFBQt2gQIAGroLf/nn7l1dO9cIW1FPrP7y3SxdIVaaFi s6BmVDhvoMGbI+PNmBF/2PNu7qFy8cDAxp9OdRoL9TVuA5Xa9JVnZkqrLXz5hpWkfmzx UuE9mUUXx92Q99gvpYkXqI7onhesyTaWU3ZQSYQXy1bPY31uu0DsV66WOEBgll0bLp7i 4KGg== X-Received: by 10.182.99.137 with SMTP id eq9mr9519066obb.34.1367603751649; Fri, 03 May 2013 10:55:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.85.226 with SMTP id k2ls315153qez.32.gmail; Fri, 03 May 2013 10:55:49 -0700 (PDT) X-Received: by 10.49.94.18 with SMTP id cy18mr687103qeb.14.1367603749495; Fri, 03 May 2013 10:55:49 -0700 (PDT) In-Reply-To: X-Original-Sender: marc.glisse@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:4242 Archived-At: ------=_Part_59_1628107.1367603748798 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le jeudi 2 mai 2013 23:29:55 UTC+2, Fernando Cacciola a =E9crit : > > On Thu, May 2, 2013 at 6:24 PM, Fernando Cacciola > > wrote: > >> On Thu, May 2, 2013 at 6:19 PM, Nevin Liber >> > wrote: >> >>> If we are going for consistency and correctness among everything in the= =20 >>> standard library, is this correct solution: >>> >>> operator< should be implemented in terms of operator< of the underlying= =20 >>> component(s) >>> operator=3D=3D should be implemented in terms of operator=3D=3D of the= =20 >>> underlying component(s) >>> std::less should be implemented in terms of std::less of the underlying= =20 >>> component(s) >>> std::equal_to should be implemented in terms of std::equal_to of the=20 >>> underlying component(s) >>> >>> operator>, operator<=3D, operator>=3D should be written in terms of ope= rator< >>> operator!=3D should be written in terms of operator=3D=3D >>> std::greater, std::less_equal, std::greater_equal should be written in= =20 >>> terms of std::less >>> std::not_equal_to should be written in terms of std::equal_to >>> >>> >> Actually, if we are going to fix the *entire* library, then we *could*= =20 >> chose to have all operators boild down to the underlying component(s) >> >> IIRC, the main reason for not doing so is consistency across the SCL. >> >> But let me clarify, I'm NOT saying we should do that (in fact, I like=20 > your proposal here a lot), only that we might not have a good reason to= =20 > make everything based on < and =3D=3D if we are completely consistent. > > IIRC, the issue with defining > in terms of < is that it messes up with= =20 > non-totally ordered types.=20 > OTOH, if you do have such a type (why would you, but that's not up to me)= ,=20 > I guess it would be reasonable to require you to specialize wrappers and= =20 > containers accordingly (which is always possible in any case) > But why should I, as someone using a non total order, have to specialize=20 anything? If the underlying type has operator>, then optional should use it= =20 for >. If it doesn't, then optional shouldn't either. If you are using=20 rel_ops with T, you can just as well use rel_ops with optional. --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/?hl=3Den. ------=_Part_59_1628107.1367603748798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le jeudi 2 mai 2013 23:29:55 UTC+2, Fernando Cacciola a =E9crit :
On Thu, May 2, 2013 at 6:24 PM, Fernando Cacciola <fernando...@gmail.com> wrote:
On Thu, May 2, 2013 at 6:19 PM, Nevin Liber <= ;ne...@eviloverlord.com> wrote:
If we are go= ing for consistency and correctness among everything in the standard librar= y, is this correct solution:

operator< should be implemented in terms of operator< of the unde= rlying component(s)
operator=3D=3D should be implemented in terms of ope= rator=3D=3D of the underlying component(s)
std::less should be implement= ed in terms of std::less of the underlying component(s)
std::equal_to should be implemented in terms of std::equal_to of the underl= ying component(s)

operator>, operator<=3D, operator>=3D sho= uld be written in terms of operator<
operator!=3D should be written i= n terms of operator=3D=3D
std::greater, std::less_equal, std::greater_equal should be written in term= s of std::less
std::not_equal_to should be written in terms of std::equa= l_to


Actually, if we are going = to fix the *entire* library, then we *could* chose to have all operators bo= ild down to the underlying component(s)

IIRC, the main re= ason for not doing so is consistency across the SCL.

But let me clar= ify, I'm NOT saying we should do that (in fact, I like your proposal here a= lot), only that we might not have a good reason to make everything based o= n < and =3D=3D if we are completely consistent.

IIRC, the issue with defining > in terms of < is that = it messes up with non-totally ordered types.
OTOH, if you do= have such a type (why would you, but that's not up to me), I guess it woul= d be reasonable to require you to specialize wrappers and containers accord= ingly (which is always possible in any case)

But why should I, as someone using a non total order, have t= o specialize anything? If the underlying type has operator>, then option= al should use it for >. If it doesn't, then optional shouldn't either. I= f  you are using rel_ops with T, you can just as well use rel_ops with= optional<T>.

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-pro= posals/?hl=3Den.
 
 
------=_Part_59_1628107.1367603748798-- .