220 4270 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:41:45 -0400 Lines: 363 Approved: news@gmane.org Message-ID: 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=089e0118451004e17004dbda92f8 X-Trace: ger.gmane.org 1367631710 30923 80.91.229.3 (4 May 2013 01:41:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 May 2013 01:41:50 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCUZ5QWKNQINZTURRQCRUBD2JS3OI@isocpp.org Sat May 04 03:41:50 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f69.google.com ([74.125.82.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UYRTy-0001kw-Ca for gclcip-std-proposals@m.gmane.org; Sat, 04 May 2013 03:41:50 +0200 Original-Received: by mail-wg0-f69.google.com with SMTP id l18sf3246909wgh.4 for ; Fri, 03 May 2013 18:41:50 -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=Fx48Oqc1Zs5fhzyqHWi5ghy0cppxv9KZOuisQlrWGa4=; b=m3bNnZWRG4uJgGcJhdX47Ti+1cyDghXhppyhP0S7wPdYsDPlK3kalka09SJS0lmVfI Xo5vSL8QkrzIU1lK7Xt7kN91MBCGTIao0IyB/7J41gZv9jFtvxJOxDrjh3UXFysi7IUk RbjMBsiZqKC4PYwYBfxs2FRQV6zddbfTKm/y524VJGxA0YCDQVbWzvbrjuQ2odFiNFGE 8sRcrq/kxXLBm9kZ5iSC/hhhvWDnknUS37c0VWgKdUyfGwjqLLUINb+9dagaOsuP34Bj Diord1vNRNX6SRDd9zo8qZX8BkWU/9AKi9pW+bs7eqg7snErcQdSxBGJDWnW05PljDXg X-Received: by 10.112.125.10 with SMTP id mm10mr14100873lbb.23.1367631709528; Fri, 03 May 2013 18:41:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.43.198 with SMTP id y6ls191637lal.25.gmail; Fri, 03 May 2013 18:41:47 -0700 (PDT) X-Received: by 10.112.135.228 with SMTP id pv4mr5112304lbb.93.1367631707142; Fri, 03 May 2013 18:41:47 -0700 (PDT) Original-Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [2a00:1450:4010:c03::235]) by mx.google.com with ESMTPS id j9si2693844laj.233.2013.05.03.18.41.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 May 2013 18:41:46 -0700 (PDT) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 2a00:1450:4010:c03::235 as permitted sender) client-ip=2a00:1450:4010:c03::235; Original-Received: by mail-la0-f53.google.com with SMTP id eo20so1991200lab.40 for ; Fri, 03 May 2013 18:41:46 -0700 (PDT) X-Received: by 10.112.163.105 with SMTP id yh9mr5083906lbb.63.1367631705987; Fri, 03 May 2013 18:41:45 -0700 (PDT) Original-Received: by 10.112.2.167 with HTTP; Fri, 3 May 2013 18:41:45 -0700 (PDT) In-Reply-To: X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 2a00:1450:4010:c03::235 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:4270 Archived-At: --089e0118451004e17004dbda92f8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 3, 2013 at 7:50 PM, Ville Voutilainen < ville.voutilainen@gmail.com> wrote: > > > > On 4 May 2013 00:19, Tony V E wrote: > >> >> You know that we will never change tuple, unless we can somehow come up >> with a backwards compatible change (ie generate > only if not defined by >> underlying type - that would at least break *less* people). >> >>> >>> I don't have any idea how you come to the conclusion that I "know" that. >>> >> >> Because you have been around the committee long enough to know how rarely >> it breaks backwards compatibility. Maybe "know" was too strong, but close. >> > > I've been around the committee long enough to know that it breaks > backwards compatibility in every > (F)CD it releases, if need be. > > >> I don't understand why optional should act differently from a tuple, >> especially for cases when the >> >>> optional is engaged. >>> >>> >> >> Really, don't understand? I assume you understand my reasoning, and just >> find it unconvincing: >> > > Really, "don't understand why optional _should_", if we read what I wrote > without cherry-picking > individual words out of context. That's perhaps less a statement about my > cognitive capabilities, > and more a statement about my finding the reasoning unconvincing. > > OK, their your words, so I'll take your word for it :-) (But I could see myself saying "I understand why optional should work like tuple, I also understand why it shouldn't". Regardless of which I found most convincing.) > > >> Neither tuple nor optional is a T. optional may currently act >>> more like a T, but it does that for comparisons >>> only, and that's for convenience. >>> >> >> And comparisons are what we are talking about. (Also, not 'only' >> comparisons - it also already has the implicit converting constructor - >> another indicator of a *design* of 'act like T', and assignment from T.) >> > > Yes, and the convenience remark above is trying to say that those > comparisons are for convenience, not > for making optional act like a T. The difference is thin, but it's > there. > > >> >> Whenever you treat these library wrappers, especially for cases when the >>> optional is engaged, in a generic >>> manner. >>> >> >> >> Yes, code that is using a template-template where the template-template >> might be an optional or a tuple... >> > > template bool operator<(const T& t, int i) > { > return t } > > No need for a template-template there. > So T is either optional or tuple (or more likely optional or tuple)? And assuming tuple < i some day works? Or do I misunderstand? > >> >> >> >>> >>> >>>> There *will* be code that is surprised that optional ordered T >>>> differently than T did. Not much code, but some. >>>> >>> >>> I would love to see an example of such code, then. >>> >> >> People do use doubles. People do use NaN behaviour. >> > > I don't find that a convincing argument. boost::optional was shipped in > 2003 and it doesn't treat doubles > transparently, so it has always had the NaN behaviour you say is > problematic. Ever since I actually > tested the NaN case with boost::optional, I have become convinced that it > would need a much stronger > argument to change that behaviour than what we have > > >> People do make > different than < for their own types. I agree that they >> typically shouldn't, but we allow it, and they do it. The odd time it >> might even be for a good reason. >> >> We assume people will use optional. The intersection may be small, but >> probably not empty. >> > > And I find it perfectly reasonable to not support such types transparently. > Note that if you don't care about NaN and such types, then you probably shouldn't care about this issue at all. For any "sane" types, either definition of optional gives the same answer. Tony -- --- 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. --089e0118451004e17004dbda92f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 3, 2013 at 7:50 PM, Ville Voutilainen <ville= ..voutilainen@gmail.com> wrote:



On 4 May 2013 00:19, Tony V E <= span dir=3D"ltr"><tvaneerd@gmail.com> wrote:

You kn= ow that we will never change tuple, unless we can somehow come up with a ba= ckwards compatible change (ie generate > only if not defined by underlyi= ng type - that would at least break *less* people).

I don't have any idea how you come to th= e conclusion that I "know" that.

Because you have been around the committee lo= ng enough to know how rarely it breaks backwards compatibility.=A0 Maybe &q= uot;know" was too strong, but close.

I've bee= n around the committee long enough to know that it breaks backwards compati= bility in every
(F)CD it releases, if need be.
=A0
I do= n't understand why optional should act differently from a tuple, especi= ally for cases when the
optional is engaged.
=A0

Really, don't = understand?=A0 I assume you understand my reasoning, and just find it uncon= vincing:

Really, "don't understand why optional _should_", if we read = what I wrote without cherry-picking
individual words out of context. That's perhaps less a state= ment about my cognitive capabilities,
and more a statement about my find= ing the reasoning unconvincing.
=A0

OK, their your words, so I'll take your word for it= :-)=A0
(But I could see myself saying "I understand why opt= ional should work like tuple, I also understand why it shouldn't".= =A0Regardless of which I found most convincing.)
=A0


=
Neither tuple<T> nor optional<T>= ; is a T. optional<T> may currently act more like a T, but it does th= at for comparisons
only, and that's for convenience.

And comparis= ons are what we are talking about.=A0 (Also, not 'only' comparisons= - it also already has the implicit converting constructor - another indica= tor of a *design* of 'act like T', and assignment from T.)

Yes, and the= convenience remark above is trying to say that those comparisons are for c= onvenience, not
for making optional<T> act like a T. Th= e difference is thin, but it's there.
=A0

Whenever you treat these library wrappers, especially for cases when the o= ptional is engaged, in a generic
manner.


Yes, code that is using a template-template w= here the template-template might be an optional or a tuple...

template <class T&g= t; bool operator<(const T& t, int i)
{
=A0=A0 return t<i;
}

No = need for a template-template there.

So T is either optional<X> or tuple<X> (or= more likely optional<int> or tuple<int>)? =A0And assuming tupl= e<int> < i some day works? =A0Or do I misunderstand?

=A0

=A0
=A0
There *will* be code that is surprised that optional ordered T = differently than T did.=A0 Not much code, but some.

I would love to see an example of su= ch code, then.

People do use doubles.=A0 People do use NaN behaviour.

I don't find that a = convincing argument. boost::optional was shipped in 2003 and it doesn't= treat doubles
transparently, so it has always had the NaN behaviour you= say is problematic. Ever since I actually
tested the NaN case with boost::optional, I have become convinced that it w= ould need a much stronger
argument to change that behaviour than what we= have


People do make > different than < for their own types.=A0 I agree tha= t they typically shouldn't, but we allow it, and they do it.=A0 The odd= time it might even be for a good reason.

We assume peopl= e will use optional. The intersection may be small, but probably not empty.=

And I find i= t perfectly reasonable to not support such types transparently.

=A0
Note that if= you don't care about NaN and such types, then you probably shouldn'= ;t care about this issue at all. =A0For any "sane" types, either = definition of optional gives the same answer.

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.
 
 
--089e0118451004e17004dbda92f8-- .