220 4431 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: Wed, 15 May 2013 17:40:11 +0300 Lines: 118 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3311226fdc804dcc2baaa X-Trace: ger.gmane.org 1368628815 30176 80.91.229.3 (15 May 2013 14:40:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 May 2013 14:40:15 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBTF4Z2GAKGQERG2YOUY@isocpp.org Wed May 15 16:40:15 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ia0-f197.google.com ([209.85.210.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UccsH-0000Zo-Sv for gclcip-std-proposals@m.gmane.org; Wed, 15 May 2013 16:40:14 +0200 Original-Received: by mail-ia0-f197.google.com with SMTP id y26sf3076083iab.8 for ; Wed, 15 May 2013 07:40:13 -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=BtDIrz8IK2y0DyNZiDY2htNAE9gnLh9MGHScmzO99DI=; b=dGY4144mp3GnPKSAxlEuwug3FFsx9ALPJkSrCxYPyQ1t3RH30ZwzGWcQ6iNfRsiTv5 efMalaUpC8BPOgV9L/8/kHmfzAdRm8n75QvRDo4pYPN2vGu7qk6ox91edF4ajRQdNpo9 tpsuzqynngnZfqhk/3bytx13DCKzOMpDRaHCXDGFkjJc90PPoMmY7AzYh4RJJ0DqCTVo 1BeTJhHExJQmmeIdPmEXQz5ijDU+i2MHA70Cn5cmyKLaHh8RyPA8sOvxyxbslwtMZ/ua D2fg8aKGrRi00G4zM9b6aeWvlSR0Umkeh7FfhpBBikWbYK6AinRlV8ZIq2hnFpKHc5SF X-Received: by 10.182.138.65 with SMTP id qo1mr11304425obb.11.1368628812914; Wed, 15 May 2013 07:40:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.114.197 with SMTP id ji5ls120422obb.8.gmail; Wed, 15 May 2013 07:40:11 -0700 (PDT) X-Received: by 10.182.120.134 with SMTP id lc6mr17156222obb.34.1368628811872; Wed, 15 May 2013 07:40:11 -0700 (PDT) Original-Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [2607:f8b0:4003:c01::232]) by mx.google.com with ESMTPS id fi6si1915031obc.10.2013.05.15.07.40.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 07:40:11 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:4003:c01::232 as permitted sender) client-ip=2607:f8b0:4003:c01::232; Original-Received: by mail-ob0-f178.google.com with SMTP id v19so2082187obq.9 for ; Wed, 15 May 2013 07:40:11 -0700 (PDT) X-Received: by 10.182.230.198 with SMTP id ta6mr17146967obc.98.1368628811724; Wed, 15 May 2013 07:40:11 -0700 (PDT) Original-Received: by 10.76.10.130 with HTTP; Wed, 15 May 2013 07:40:11 -0700 (PDT) In-Reply-To: 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 2607:f8b0:4003:c01::232 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:4431 Archived-At: --001a11c3311226fdc804dcc2baaa Content-Type: text/plain; charset=ISO-8859-1 On 15 May 2013 17:20, Ville Voutilainen wrote: > > > > On 15 May 2013 17:04, Fernando Cacciola wrote: > >> >> I'd prefer if as much as possible each issue was a separate paper. >>> Optional operator> separate from optional std::less. tuple/pair separate >>> from optional. >>> >> >> Agreed. >> >> > My preference would be to separate out std::less specializations > (tuple doesn't work as a key for > an ordered associative container), but keep the other part, the discussion > about relational operators > themselves, in a single paper. The pros/cons of what we do with optional's > operator> are strongly > related to tuple/boost::tuple/containers, so I don't think we should split > these into separate tuple > and optional papers. > > I think it's clearest if, as mentioned, the std::less paper is completely separate, then we have a collective analysis paper, and separate wording papers for the options. The last bit is actually quite good to have, so that people don't accidentally scroll to the wrong wording. We had that issue with optional wording being present in the optional paper. Good enough compromise? -- --- 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. --001a11c3311226fdc804dcc2baaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 15 May 2013 17:20, Ville Voutilainen <ville.voutilain= en@gmail.com> wrote:



On 15 May 2013 17:= 04, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
=

I'd prefer if as much as po= ssible each issue was a separate paper. =A0Optional operator> separate f= rom optional std::less. =A0tuple/pair separate from optional.

Agreed.

My pre= ference would be to separate out std::less specializations (tuple<T*>= doesn't work as a key for
an ordered associative container), but keep the other part, the discussion = about relational operators
themselves, in a single paper. The pros/cons = of what we do with optional's operator> are strongly
related to t= uple/boost::tuple/containers, so I don't think we should split these in= to separate tuple
and optional papers.


I think it's cl= earest if, as mentioned, the std::less paper is completely separate, then w= e have a collective
analysis paper, and= separate wording papers for the options. The last bit is actually quite go= od to
have, so that people don't accidentally scroll to the wrong wording. We= had that issue with
optional<T&= > wording being present in the optional paper.

Good enough compromise?

--
 
---
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.
 
 
--001a11c3311226fdc804dcc2baaa-- .