220 4266 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen 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 02:52:53 +0300 Lines: 71 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=047d7b2e0887a2133604dbd90ce3 X-Trace: ger.gmane.org 1367625176 12256 80.91.229.3 (3 May 2013 23:52:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 May 2013 23:52:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBVM3SGGAKGQE5QYUTQA@isocpp.org Sat May 04 01:52:56 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f69.google.com ([209.85.219.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UYPmZ-0005qt-Ah for gclcip-std-proposals@m.gmane.org; Sat, 04 May 2013 01:52:55 +0200 Original-Received: by mail-oa0-f69.google.com with SMTP id k14sf12976457oag.8 for ; Fri, 03 May 2013 16:52:54 -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=MysG1z1XZ0++MGhLigCt+k6ls3qEvPR7SL5a+0L4hgg=; b=mmpMsppuxrXX/+ZU6ZgwbCMi2+7nVEXRC9F1dU0ARSiKkMnVs7plhXDGdVb3rXNG2L kFdV3Ek9lGQRpMsP2NcWZ2aAhdbJ4ttgFZbr8u4jlB/c+atSsPTJ6c3QPqRZf7YzTHqy H2NnqIzi7tvoh2S7N6jOAJvSk5inTsrk+NOyEUj6b4P+Ca0hJ96yE+NvPcj+5JPFAJTu +Z84cx5kwJOPogfqpFaSCgwim7OLrKQcYRPaus+FOB21IJARAk3xiujR8fKItvZBzb4p Ohgp7A+tsDQ0oV1/ktRw9RHtHnp6t+sK390ZlGVVfEW0HP9EvAh5zIFcLZ7Jht129Fbw X-Received: by 10.182.34.200 with SMTP id b8mr10520643obj.0.1367625174051; Fri, 03 May 2013 16:52:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.117.233 with SMTP id kh9ls273760obb.17.gmail; Fri, 03 May 2013 16:52:53 -0700 (PDT) X-Received: by 10.60.98.235 with SMTP id el11mr3514443oeb.57.1367625173281; Fri, 03 May 2013 16:52:53 -0700 (PDT) Original-Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by mx.google.com with ESMTPS id ut5si3332696obc.31.2013.05.03.16.52.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 May 2013 16:52:53 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 209.85.219.47 as permitted sender) client-ip=209.85.219.47; Original-Received: by mail-oa0-f47.google.com with SMTP id m1so2126428oag.20 for ; Fri, 03 May 2013 16:52:53 -0700 (PDT) X-Received: by 10.60.142.103 with SMTP id rv7mr3530965oeb.34.1367625173175; Fri, 03 May 2013 16:52:53 -0700 (PDT) Original-Received: by 10.76.10.130 with HTTP; Fri, 3 May 2013 16:52:53 -0700 (PDT) In-Reply-To: <47de7d1c-0f32-43f6-9e26-952b87b44dc1@isocpp.org> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 209.85.219.47 as permitted sender) smtp.mail=ville.voutilainen@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:4266 Archived-At: --047d7b2e0887a2133604dbd90ce3 Content-Type: text/plain; charset=ISO-8859-1 On 4 May 2013 01:09, Marc wrote: > > But mostly, the rational 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 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 have no trouble with the name of std::less. What I wrote before was that I'd prefer not using std::less for ordering keys of associative container. ;) -- --- 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 email 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-proposals/?hl=en. --047d7b2e0887a2133604dbd90ce3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 4 May 2013 01:09, Marc <marc.glisse@gmail.com> wrote:

But mostly, the rational for provid= ing 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 should have had = a better name), so in my opinion std::optional should simply not provide op= erator< at all. That seems the safest thing.

--


I have no trouble wi= th the name of std::less. What I wrote before was that I'd prefer not u= sing std::less for
ordering keys of associative container. ;)=

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