220 4274 article Path: news.gmane.org!not-for-mail From: Rafael Fourquet 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 16:33:19 +0530 Lines: 115 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=089e0122f12eb49e7f04dbe26c0f X-Trace: ger.gmane.org 1367665445 4188 80.91.229.3 (4 May 2013 11:04:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 May 2013 11:04:05 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDJOLOXJVYOBBIWWSOGAKGQE526563I@isocpp.org Sat May 04 13:04:05 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qe0-f69.google.com ([209.85.128.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UYaG4-0007fs-Fz for gclcip-std-proposals@m.gmane.org; Sat, 04 May 2013 13:04:04 +0200 Original-Received: by mail-qe0-f69.google.com with SMTP id a11sf4528768qen.0 for ; Sat, 04 May 2013 04:04:03 -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:x-received :mime-version:in-reply-to:references:from:date:message-id:subject: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=8FTYPPRv0F5f5ZWg1UMNzEHDS1fQFuUf3ehFlFsyYEY=; b=EAldZKcvb/5tNrXxXn8K31yPCEPi0jVCfaY2H4ObDwAxwilj0Af7XoIxUnnCxymtOI IFCv+XTbqU8n59MvDc3qtLs7oL9Mx4Yb6nY1tI2CNGxImI8T7b+uzxmxZJUjDnK7s9RK Aqaz9JZbwmFtZG/ODDMzUyFptsP/Y4hRuKPpKCV6eiYwXfxotXlPd+qBh3SX+piJ9OFO uAWsMntNIBfAy27D63AcXFXlHo/qQQrLwjONsT/JbRLklDbMBIbPvZ/1AtYgMcNe3Dv+ 8WIQXWs4aV8I/721KJ03SzX83HGeESXbTN7hr2HTM0UKCge7dSAegJnxRvERosXoltD/ X-Received: by 10.236.62.166 with SMTP id y26mr10459949yhc.39.1367665443429; Sat, 04 May 2013 04:04:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.74.66 with SMTP id r2ls167391qev.48.gmail; Sat, 04 May 2013 04:04:00 -0700 (PDT) X-Received: by 10.52.174.196 with SMTP id bu4mr3949773vdc.117.1367665440909; Sat, 04 May 2013 04:04:00 -0700 (PDT) Original-Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by mx.google.com with ESMTPS id s9si6732662vco.85.2013.05.04.04.03.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 May 2013 04:03:59 -0700 (PDT) Received-SPF: pass (google.com: domain of fourquet.d@gmail.com designates 209.85.220.174 as permitted sender) client-ip=209.85.220.174; Original-Received: by mail-vc0-f174.google.com with SMTP id hf12so2052175vcb.5 for ; Sat, 04 May 2013 04:03:59 -0700 (PDT) X-Received: by 10.52.120.83 with SMTP id la19mr2277025vdb.58.1367665439708; Sat, 04 May 2013 04:03:59 -0700 (PDT) Original-Received: by 10.58.231.42 with HTTP; Sat, 4 May 2013 04:03:19 -0700 (PDT) In-Reply-To: X-Original-Sender: fourquet.d@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of fourquet.d@gmail.com designates 209.85.220.174 as permitted sender) smtp.mail=fourquet.d@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:4274 Archived-At: --089e0122f12eb49e7f04dbe26c0f Content-Type: text/plain; charset=ISO-8859-1 FWIW, as a simple user: I wouldn't by default expect (and rely on) tuple to take into account all my comparisons operators (but why not?), I can accept there has to be compromises for handling generality. But I perceive optional as a very thin wrapper around T. I would be 1) fine if it didn't have comparisons operators, or only < and == for storing in containers (as a convenience for the user); 2) upset that e.g. "op1 < op2" and "op1 <= op2" and "op1 > op2" worked out of the box (for optional op1, op2), to discover only later they didn't use underlying operators defined for T (and I fail, as a non-expert, to see a situation where I would want that). I wouldn't be less upset if someone tells me it is for consistency with tuples etc. In some code, I could want to replace the type T of a variable by optional. Although it should be done carefully, I may forget in some place to change e.g. "a>=b" by "*a>=*b", and my program would then silently become wrong. I would never do a drop-in replacement of T by tuple. The point for > not to be defined in terms of < is again obviously for non-totally ordered sets. I have an example where I use a class storing only an unsigned int to be used as a binary vector. I need the following partial order: x <= y IFF x_i <= y_i for all indices i (x_i, y_i are in {0,1}). I chose "<=" because it is very close to the mathematical notation (which is like mathematical <= where the "<" is curved). But: it is also very convenient to have the usual operator< defined (in terms of < for ints, as a total order, for map/set, or in loops). C++ permits that, nice. This type is not confusing. If I want auto-generated operators, I prefer doing it explicitly, with e.g. boost::totally_ordered. -- --- 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. --089e0122f12eb49e7f04dbe26c0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FWIW, as a simple user:

I wouldn= 9;t by default expect (and rely on) tuple<T,...> to take into accou= nt all my comparisons operators (but why not?), I can accept there has to b= e compromises for handling generality.

But I perceive optional<T> as a very thin wrapper around T.= I would be

1) fine if it didn't have comparisons operators, or= only < and =3D=3D for storing in containers (as a convenience for the u= ser);

2) upset that e.g. "op1=A0 < op2" and "op1 <=3D op= 2" and "op1 > op2" worked out of the box (for optional<= ;T> op1, op2), to discover only=A0 later they didn't use underlying = operators defined for T (and I fail, as a non-expert, to see a situation wh= ere I would want that). I wouldn't be less upset if someone tells me it= is for consistency with tuples etc.
In some code, I could want to replace the type T of a variable by optional&= lt;T>. Although it should be done carefully, I may forget in some place = to change e.g. "a>=3Db" by "*a>=3D*b", and my pro= gram would then silently become wrong. I would never do a drop-in replaceme= nt of T by tuple<T>.

The point f= or > not to be defined in terms of < is again obviously for non-total= ly ordered sets.
I have an example wher= e I use a class storing only an unsigned int to be used as a binary vector.= I need the following partial order: x <=3D y IFF x_i <=3D y_i for = all indices i (x_i, y_i are in {0,1}). I chose "<=3D" because = it is very close to the mathematical notation (which is like mathematical &= lt;=3D where the "<" is curved).=A0 But: it is also very conve= nient to have the usual operator< defined (in terms of < for ints, = as a total order, for map/set, or in loops). C++ permits that, nice. This t= ype is not confusing.

If I want auto-generated operators, I = prefer doing it explicitly, with e.g. boost::totally_ordered.

=

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