220 4273 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: Sat, 4 May 2013 01:30:27 -0700 (PDT) Lines: 213 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="----=_Part_754_24065199.1367656227501" X-Trace: ger.gmane.org 1367656237 25214 80.91.229.3 (4 May 2013 08:30:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 May 2013 08:30:37 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCGJRE7HX4IBBJ4OSOGAKGQE7HT34JY@isocpp.org Sat May 04 10:30:37 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f70.google.com ([209.85.213.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UYXrW-0003Hf-4R for gclcip-std-proposals@m.gmane.org; Sat, 04 May 2013 10:30:34 +0200 Original-Received: by mail-yh0-f70.google.com with SMTP id b41sf4345480yha.9 for ; Sat, 04 May 2013 01:30: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: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=h9Ps7GLkNF1bUevOTUh0j4B29B6GX/fJ8pre/VRjkDc=; b=u1QVzJ3M4Wl93LOGVOF8ug4R623+1X5Y1sA1OY0/bVvgt5EKDZvNsU2MaN875AXsqy eN3MDkOFn86S0WFbh7mmH2vvibCBs6cpwHihHSqblUei3BjQPD0bP9yjPxMROW/9sd8P QLateQGTozFvhWbbHR/iAPt73yosAMo/8hAInu4IfYM5NfCDRseoQL8URXf2gakAWzgL FYb7AgRdNsKgPxtTF/vAZoiEBvsmxoFIik+bCSSPLtxX/4k9V9dyMZFoLgPKDjrFbAAy lejHWnHHmeCR2nesEzeU4LamaFdFRjWYZoDKnon6uWK7tCZBiKiex2jQL+BQPIAembp7 HhBA== X-Received: by 10.58.75.169 with SMTP id d9mr12047388vew.14.1367656233032; Sat, 04 May 2013 01:30:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.25.138 with SMTP id c10ls2354537qeg.29.gmail; Sat, 04 May 2013 01:30:28 -0700 (PDT) X-Received: by 10.49.2.170 with SMTP id 10mr1225043qev.40.1367656228537; Sat, 04 May 2013 01:30:28 -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:4273 Archived-At: ------=_Part_754_24065199.1367656227501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le samedi 4 mai 2013 03:42:31 UTC+2, Tony V E a =E9crit : > > On Fri, May 3, 2013 at 6:09 PM, Marc >wr= ote: > >> It is not clear how to define a lexicographic ordering (for >=3D2 elemen= ts)=20 >> based on a weird ordering of the elements, so basing it on < only is not= an=20 >> absurd choice=20 > > > It is actually the same as how it is done for <. My initial thought was= =20 > the same - that it would need to work differently (ie back to front or=20 > something) but it doesn't. > But for a weird ordering, it isn't clear that you want the lexicographic <= =3D=20 to be defined only in terms of <=3D, defining it with some mix of < and <= =3D=20 might make more sense. And since there is no clear answer... (not providing those operators might have been better, I don't think=20 >> special casing containers of size 1 would be a good idea). On the other= =20 >> hand, it is obvious how to define an ordering on T based on a weird=20 >> ordering on T. So if operator> is provided on optional and operator>= =20 >> disagrees between T and tuple, I'd rather have it return the same as= =20 >> with T. While I am here, I would also argue that it shouldn't return boo= l=20 >> but decltype(auto), in case operator< returns a tribool for instance. An= d=20 >> maybe add a noexcept(auto) (using the current heavy syntax instead)? >> >> > Interesting. We can't actually return decltype(auto) unless we allow T t= o=20 > decide how nullopt and T compare. optional decides how nullopt is=20 > ordered against T (nullopt is least-most) - and returns true or false for= =20 > that comparison, then lets T order the rest. So you either dictate that= =20 > the return type be at least convertible from bool, or give the client som= e=20 > way to define how nullopt is ordered (via traits or something). > The example implementation for operator< had a single return statement, so= =20 using decltype(auto) should be ok (although something more explicit could= =20 be better), and it used cond?true:(*a<*b) which is already assuming that=20 bool and the return type can find some common type. =20 > But mostly, the rational for providing operator< seems to be so we can pu= t=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 >> >> I'd be OK with that if there was an easy way to enable the comparisons= =20 > when you actually did want them (an opt-in strategy). ie - easier than=20 > writing them all yourself. > But why for comparisons in particular? Why not for operator+ as well (it=20 could return a disengaged result whenever one argument is disengaged, like= =20 a NaN)? By the way, comparisons could return an optional (aka=20 tribool), it would make just as much sense. And maybe overload operator. (I= =20 know it doesn't exist) to forward to members of T? optional has an=20 interface similar to pointers, and... well, we do seem to provide all the= =20 comparisons on shared_ptr (they forward to the underlying pointer). It seems to me that providing operator< (and the others) is outside the=20 scope of optional. Whereas providing a specialization for=20 std::default_arbitrary_set_ordering (aka std::less) and std::hash and=20 possibly an overload for =3D=3D (and maybe !=3D) is what's needed for a goo= d=20 integration with the rest of the standard library. But re-reading through= =20 the library, I see that providing all the comparison operators is what's=20 done everywhere, so I'll stop complaining and simply refrain from using=20 optional in sensitive cases. Sorry for contributing to the extra-length of this discussion. --=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_754_24065199.1367656227501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le samedi 4 mai 2013 03:42:31 UTC+2, Tony V E a =E9crit :
On Fri, May 3, 2013 at 6:09 PM, Marc <marc= .....@gmail.com> wrote:
It is not clear how to define a lexicographi= c ordering (for >=3D2 elements) based on a weird ordering of the element= s, so basing it on < only is not an absurd choice=20

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

But for a weird ordering, it isn't clear th= at you want the lexicographic <=3D to be defined only in terms of <= =3D, defining it with some mix of < and <=3D might make more sense. A= nd since there is no clear answer...

(not providing those operators m= ight have been better, I don't think special casing containers of size 1 wo= uld be a good idea). On the other hand, it is obvious how to define an orde= ring on T based on a weird ordering on T. So if operator> is provided on= optional<T> and operator> disagrees between T and tuple<T>,= I'd rather have it return the same as with T. While I am here, I would als= o argue that it shouldn't return bool but decltype(auto), in case operator&= lt; returns a tribool for instance. And maybe add a noexcept(auto) (using t= he current heavy syntax instead)?


Interesting.  We can't actu= ally return decltype(auto) unless we allow T to decide how nullopt and T co= mpare.  optional<T> decides how nullopt is ordered against T (nu= llopt 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 n= ullopt is ordered (via traits or something).

The example implementation for operator< had a single ret= urn statement, so using decltype(auto) should be ok (although something mor= e explicit could be better), and it used cond?true:(*a<*b) which is alre= ady assuming that bool and the return type can find some common type.
&n= bsp;
But mostly, the rational for providing = operator< seems to be so we can put it in an std::set, but that's alread= y 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&l= t; 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 st= rategy). ie - easier than writing them all yourself.

But why for comparisons in particular? Why not for o= perator+ as well (it could return a disengaged result whenever one argument= is disengaged, like a NaN)? By the way, comparisons could return an option= al<bool> (aka tribool), it would make just as much sense. And maybe o= verload operator. (I know it doesn't exist) to forward to members of T? opt= ional has an interface similar to pointers, and... well, we do seem to prov= ide all the comparisons on shared_ptr (they forward to the underlying point= er).

It seems to me that providing operator< (and the others) is = outside the scope of optional. Whereas providing a specialization for std::= default_arbitrary_set_ordering (aka std::less) and std::hash and possibly a= n overload for =3D=3D (and maybe !=3D) is what's needed for a good integrat= ion with the rest of the standard library. But re-reading through the libra= ry, I see that providing all the comparison operators is what's done everyw= here, so I'll stop complaining and simply refrain from using optional in se= nsitive cases.

Sorry for contributing to the extra-length of this di= scussion.

--
 
---
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_754_24065199.1367656227501-- .