220 4264 <47de7d1c-0f32-43f6-9e26-952b87b44dc1@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 15:09:30 -0700 (PDT) Lines: 116 Approved: news@gmane.org Message-ID: <47de7d1c-0f32-43f6-9e26-952b87b44dc1@isocpp.org> References: <5f236e41-0f5f-4288-a80f-9eadb5168c38@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_168_4037042.1367618970991" X-Trace: ger.gmane.org 1367618977 22016 80.91.229.3 (3 May 2013 22:09:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 May 2013 22:09:37 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCGJRE7HX4IBBHXLSCGAKGQEVRRV42I@isocpp.org Sat May 04 00:09:37 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gg0-f200.google.com ([209.85.161.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UYOAa-0005U5-37 for gclcip-std-proposals@m.gmane.org; Sat, 04 May 2013 00:09:36 +0200 Original-Received: by mail-gg0-f200.google.com with SMTP id h13sf2760602ggd.7 for ; Fri, 03 May 2013 15:09:35 -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=7zkF1geRT0c9pzaMvrVM8Md+rItI1fhsIGqwRQNSrIE=; b=dse6Vf5yV24HBTGjsRBiyhCpeaCsGsybKEMLrDMO5y08jcJMmVTY6Fk+KD6BAQzJkB Qb+Dt21uS1hPLI404oREIjn/azNWlqZhg18sh4vTSvy8EQZ9B/wxyPOAwV2PBmOFBDIh NGKzLYAXKDr2tnLZrc+yEmaD7KOfjHtXZC499yZyCZv5UVRQ9L88Ev/QOJZuXrMODoYx ocx+6bsSPLKa4pxH+G5lZxYpF7uI19WxK6NW0tKcxqxqrR1/Tmtx/pa5LhQbgDaHryru Q9jO6EwVCaPkpBkCNTc0ccZUOiXBg9J4sT+0lWA4LnMnuMpYlz5djX7opmBck53GQRr8 CuoQ== X-Received: by 10.236.84.177 with SMTP id s37mr9017892yhe.37.1367618975132; Fri, 03 May 2013 15:09:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.5.10 with SMTP id o10ls2040351qeo.69.gmail; Fri, 03 May 2013 15:09:32 -0700 (PDT) X-Received: by 10.49.130.7 with SMTP id oa7mr1194557qeb.12.1367618972058; Fri, 03 May 2013 15:09:32 -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:4264 Archived-At: ------=_Part_168_4037042.1367618970991 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le vendredi 3 mai 2013 20:12:40 UTC+2, Ville Voutilainen a =E9crit : > > > On 3 May 2013 20:55, Marc > wrote: > >> >> 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 >> Currently tuple, pair and containers don't do that. It would be=20 > reasonable to be consistent in that regard > with optional, and consider further changes separately afterwards. > It is not clear how to define a lexicographic ordering (for >=3D2 elements)= =20 based on a weird ordering of the elements, so basing it on < only is not an= =20 absurd choice (not providing those operators might have been better, I=20 don't think special casing containers of size 1 would be a good idea). On= =20 the other hand, it is obvious how to define an ordering on T based on a=20 weird ordering on T. So if operator> is provided on optional and=20 operator> disagrees between T and tuple, I'd rather have it return the= =20 same as with T. While I am here, I would also argue that it shouldn't=20 return bool but decltype(auto), in case operator< returns a tribool for=20 instance. And maybe add a noexcept(auto) (using the current heavy syntax=20 instead)? But mostly, the rational for providing operator< seems to be so we can put= =20 it in an std::set, but that's already handled by specializing std::less=20 (which I agree should have had a better name), so in my opinion=20 std::optional should simply not provide operator< at all. That seems the=20 safest thing. --=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_168_4037042.1367618970991 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le vendredi 3 mai 2013 20:12:40 UTC+2, Ville Voutilainen a =E9crit :

On 3 May 2013 20:55, Marc <= marc....@gmail.com> wrote:

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

Currently tuple, pair and containers don'= t do that. It would be reasonable to be consistent in that regard
with o= ptional, and consider further changes separately afterwards.

It is not clear how to define a lexicogr= aphic ordering (for >=3D2 elements) based on a weird ordering of the ele= ments, so basing it on < only is not an absurd choice (not providing tho= se operators might have been better, I don't think special casing container= s of size 1 would be a good idea). On the other hand, it is obvious how to = define an ordering on T based on a weird ordering on T. So if operator> = is provided on optional<T> and operator> disagrees between T and t= uple<T>, I'd rather have it return the same as with T. While I am her= e, I would also argue that it shouldn't return bool but decltype(auto), in = case operator< returns a tribool for instance. And maybe add a noexcept(= auto) (using the current heavy syntax instead)?

But mostly, the rati= onal for providing operator< seems to be so we can put it in an std::set= , but that's already handled by specializing std::less (which I agree shoul= d have had a better name), so in my opinion std::optional should simply not= provide operator< at all. That seems the safest thing.

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