220 4271 article Path: news.gmane.org!not-for-mail From: Tony V E 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 21:42:31 -0400 Lines: 182 Approved: news@gmane.org Message-ID: References: <5f236e41-0f5f-4288-a80f-9eadb5168c38@isocpp.org> <47de7d1c-0f32-43f6-9e26-952b87b44dc1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b3441febaa86604dbda9472 X-Trace: ger.gmane.org 1367631756 31271 80.91.229.3 (4 May 2013 01:42:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 May 2013 01:42:36 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCUZ5QWKNQIIRT4RRQCRUBFK3LJAO@isocpp.org Sat May 04 03:42:36 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f70.google.com ([74.125.82.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UYRUg-0002MP-61 for gclcip-std-proposals@m.gmane.org; Sat, 04 May 2013 03:42:34 +0200 Original-Received: by mail-wg0-f70.google.com with SMTP id z12sf3246907wgg.1 for ; Fri, 03 May 2013 18:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:received-spf:mime-version :x-received:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-google-group-id:list-post :list-help:list-archive:list-subscribe:list-unsubscribe:content-type; bh=gkDTd64leR0aMRzlcA+vZKsM0c7vDN2AO9/YBQo9qQ8=; b=gGTUUAO9hjRjQu6i4XyAc9H24+CJdbNw+LH6InUMmcQ5Lk2NAA75ZZCVotzicPAXbk 1IUeGe6bu+V96I36g/QCpCnmemOYlSjGXKvrMGIe0OuWoIyYIEsmvLF/hl4kiMzlwmGD pcdnPOD+TuEbxT7am+1wH2p8xcMi8CfVj9M2NVX7ZieF1AijhpiN5kbbYk95/Br02IWE GpH3r0E0LZUSHsO5pm+TrwBlmRGpzyV+tuGF0s1/IOHQG46P6RL/tn5QuRHrN9XEjB9x DOvqWn+RhthepWSEALucLfBgHlOClXdVBLBKyvEiGTRAg0jUi6qFdmk9d3DI99yXjvTn X-Received: by 10.112.88.168 with SMTP id bh8mr14166423lbb.7.1367631753669; Fri, 03 May 2013 18:42:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.29.66 with SMTP id i2ls180061lah.84.gmail; Fri, 03 May 2013 18:42:31 -0700 (PDT) X-Received: by 10.152.116.113 with SMTP id jv17mr4999005lab.35.1367631751602; Fri, 03 May 2013 18:42:31 -0700 (PDT) Original-Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by mx.google.com with ESMTPS id rh3si2801572lbb.121.2013.05.03.18.42.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 May 2013 18:42:31 -0700 (PDT) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 209.85.217.171 as permitted sender) client-ip=209.85.217.171; Original-Received: by mail-lb0-f171.google.com with SMTP id u10so2050115lbi.16 for ; Fri, 03 May 2013 18:42:31 -0700 (PDT) X-Received: by 10.112.128.135 with SMTP id no7mr5100207lbb.79.1367631751455; Fri, 03 May 2013 18:42:31 -0700 (PDT) Original-Received: by 10.112.2.167 with HTTP; Fri, 3 May 2013 18:42:31 -0700 (PDT) In-Reply-To: <47de7d1c-0f32-43f6-9e26-952b87b44dc1@isocpp.org> X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.217.171 as permitted sender) smtp.mail=tvaneerd@gmail.com; dkim=pass header.i=@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:4271 Archived-At: --047d7b3441febaa86604dbda9472 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 3, 2013 at 6:09 PM, Marc wrote: > 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 specializ= e >>> anything? If the underlying type has operator>, then optional should us= e it >>> for >. If it doesn't, then optional shouldn't either. If you are using >>> rel_ops with T, you can just as well use rel_ops with optional. >>> >>> Currently tuple, pair and containers don't do that. It would be >> 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 element= s) > based on a weird ordering of the elements, so basing it on < only is not = an > absurd choice > It is actually the same as how it is done for <. My initial thought was the same - that it would need to work differently (ie back to front or something) but it doesn't. > (not providing those operators might have been better, I don't think > special casing containers 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 and operator> > disagrees between T and tuple, I'd rather have it return the same as > with T. While I am here, 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)? > > Interesting. We can't actually return decltype(auto) unless we allow T to decide how nullopt and T compare. optional decides how nullopt is ordered against T (nullopt is least-most) - and returns true or false for that comparison, then lets T order the rest. So you either dictate that the return type be at least convertible from bool, or give the client some way to define how nullopt is ordered (via traits or something). > But mostly, the rational for providing operator< seems to be so we can pu= t > it in an std::set, but that's already handled by specializing std::less > (which I agree should have had a better name), so in my opinion > std::optional should simply not provide operator< at all. That seems the > safest thing. > > -- > > I'd be OK with that if there was an easy way to enable the comparisons when you actually did want them (an opt-in strategy). ie - easier than writing them all yourself. Tony --=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. --047d7b3441febaa86604dbda9472 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 3, 2013 at 6:09 PM, Marc <marc.glisse@gmail.com> wrote:
Le vendredi 3 mai 2013 20:12:40 UTC+2, Ville= Voutilainen a =E9crit=A0:

On 3 May 2013 20:55, M= arc <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= optional shouldn't either. If=A0 you are using rel_ops with T, you can= just as well use rel_ops with optional<T>.

Currently tuple, pair and containers don&= #39;t do that. It would be reasonable to be consistent in that regard
wi= th optional, and consider further changes separately afterwards.

It is not clear how to define= a lexicographic ordering (for >=3D2 elements) based on a weird ordering= of the elements, so basing it on < only is not an absurd choice

It is actually the same as how it is done = for <. =A0My initial thought was the same - that it would need to work d= ifferently (ie back to front or something) but it doesn't.

=A0
(not providing = those operators might have been better, I don't think special casing co= ntainers 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 operat= or> is provided on optional<T> and operator> disagrees between = T and tuple<T>, I'd rather have it return the same as with T. Whi= le I am here, I would also argue that it shouldn't return bool but decl= type(auto), in case operator< returns a tribool for instance. And maybe = add a noexcept(auto) (using the current heavy syntax instead)?


Interesting. =A0We can't act= ually return decltype(auto) unless we allow T to decide how nullopt and T c= ompare. =A0optional<T> decides how nullopt is ordered against T (null= opt is least-most) - and returns true or false for that comparison, then le= ts T order the rest. =A0So you either dictate that the return type be at le= ast convertible from bool, or give the client some way to define how nullop= t is ordered (via traits or something).

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

--
=A0=A0

I'd be OK wit= h that if there was an easy way to enable the comparisons when you actually= did want them (an opt-in strategy). ie - easier than writing them all your= self.
=A0
Tony

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