220 38674 <75095771-64a6-434c-b9d0-a9d4b1726ce5@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Three way comparison of arrays Date: Fri, 15 Jun 2018 12:03:35 -0700 (PDT) Lines: 80 Approved: news@gmane.org Message-ID: <75095771-64a6-434c-b9d0-a9d4b1726ce5@isocpp.org> References: <9c6a84e4-66a2-4a25-8372-c7a6c7b8de25@isocpp.org> <60dffd75-ebc3-4e4c-8666-f304be8f6136@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8659_1729467785.1529089415147" X-Trace: blaine.gmane.org 1529089290 16701 195.159.176.226 (15 Jun 2018 19:01:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 15 Jun 2018 19:01:30 +0000 (UTC) Cc: m.cencora@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBB43SDMQKGQELZJFVXI@isocpp.org Fri Jun 15 21:01:26 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f200.google.com ([209.85.213.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fTtyP-0004B3-CH for gclcip-std-proposals@m.gmane.org; Fri, 15 Jun 2018 21:01:25 +0200 Original-Received: by mail-yb0-f200.google.com with SMTP id d1-v6sf7430025ybq.16 for ; Fri, 15 Jun 2018 12:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=G+xBkTgPFh5U6nbQpFPVliaLmnlDtW0Mrr+WkHhLv/Q=; b=k0tcUtmNR1qt0gaMFeFFtxkl9inf2kBq188Ukii16xHkTLCukMtd6mRgGU0HijQnG1 hZ3TbNYdgdB3uoD8V23CNzYqTRKAv7KkT8XEGYy48w1tzIgGsRCJths5qJtcCdPxLIBg AZ/T+py8/TLviICvU0JtZHlNI1DyeitT3etu6IJJQQY0yQZrq8gI1++8XewyP+tnl64u /Z+BkKAj3ArBZ5LWyqPt1bO+syNlg1reaakuohl6u/GSJhIqRFQAg7gyzVmB+smhvJ5o 5cEUPKz4DQgBsQE89yrQouKMyAfuTyGQqClu2bnMrz0co8VaJzL38TqBclXSPoWNS1l2 Ij1Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=G+xBkTgPFh5U6nbQpFPVliaLmnlDtW0Mrr+WkHhLv/Q=; b=N5sFUWJhugCzJy10Y+n52WQnERYtmSAquRNTiGMP4dkr/aj77T6RkjXH+jCYi/uLcZ 2uepeAiUzHkzUudeK26yQopc/u/vhSEMpiRpUPqMopyzmHGt8BWl08ug4VysWPUdwJ1S WtFNDfmtOyD92c1pqYj93WlkHknctuRg+g7z8IrmgqMpb92ZpKJHmoF88Sir/qTVXG2K oBKeH6B1tU2HYkCm7/ObkgsebQLsiXxrVa+4F77LJNKHFsIhD/zRo5quKEagUOGNTEbS X3xAFedxK5c3TIJrXh2je3AIJ3LVZ4msl/R7SQLLayZDMD6/Ea+wYlDRCoM8WiPI8SsC uboA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=G+xBkTgPFh5U6nbQpFPVliaLmnlDtW0Mrr+WkHhLv/Q=; b=kryFP0L77NiiSZk3hF77u5RF342rub3Pez1JaKFWSK6blkM9Kw5Br1I3TeIY5d3B/f rpDuRQnPTdiKJ5tE8VYkz4EVqqe28GwZ13DpsdRjb9xD2OsIsETg8wSfdUq2hxQetX4j gbmJcK6pZ+kw/I9JOt9XvGkIbK0mc4hxZ1JAwYgtnMZV374Z1DonKB1W6OPLJYCZEvcg QOYDDlYtX+n3KGz/LGwH4yJU0jXcFnHVtKz3aWHjk0OHB/42WZYnvpi6ZG26VIzisIP5 /v6lmD+f/Z3+cTzWQjflEUVsDRumY+NanWd06Pgkf9+1oomjX4Y9TzDXu7pX4sid/72o YN6g== X-Gm-Message-State: APt69E0FWjH6yLbZ9xPRQCcarD9lj17bWAqowtU8YOAUG41z2orCeE32 QBlrFKunrs0Ghhg+/yKFm07wCg== X-Google-Smtp-Source: ADUXVKIkuzJ3++4PEm3mcw6KqMQPdg4K+9i1KWFB+u1/3ftnag6MOlEWVBCq8C21wGO6MMF6ozvkEQ== X-Received: by 2002:a25:bb91:: with SMTP id y17-v6mr793928ybg.77.1529089416441; Fri, 15 Jun 2018 12:03:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:2596:: with SMTP id l144-v6ls632755ybl.20.gmail; Fri, 15 Jun 2018 12:03:35 -0700 (PDT) X-Received: by 2002:a25:cf13:: with SMTP id f19-v6mr132545ybg.5.1529089415578; Fri, 15 Jun 2018 12:03:35 -0700 (PDT) In-Reply-To: <60dffd75-ebc3-4e4c-8666-f304be8f6136@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:38674 Archived-At: ------=_Part_8659_1729467785.1529089415147 Content-Type: multipart/alternative; boundary="----=_Part_8660_34551546.1529089415147" ------=_Part_8660_34551546.1529089415147 Content-Type: text/plain; charset="UTF-8" On Friday, June 15, 2018 at 2:45:33 PM UTC-4, m.ce...@gmail.com wrote: > > This is a weak argument. We sacrifice the consistency of the operator<=> > (works for all types) for doubtful consistency of copy and compare (of a > single type). We should be fixing language corner cases so it does what > programmer intents. > So I'd rather have operator<=> for arrays in all cases, and fix array > copying as well. > Well, here's the thing: most people will not be using `<=>` directly. They're going to use the fruits of `<=>`: the implicit generation of the other 2/6 operators in both directions. So you would need a special rule for `<=>` when applied to arrays saying that they *don't* generate the other 2/6 operations for them. That would be highly inconsistent. If comparison with those operators isn't going to work for language arrays, why should it work for `<=>`? At least with it the way it is at present, we can later (after removing the old behavior) change the behavior to work the way we want. Or we can just ditch language arrays altogether. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/75095771-64a6-434c-b9d0-a9d4b1726ce5%40isocpp.org. ------=_Part_8660_34551546.1529089415147 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Friday, June 15, 2018 at 2:45:33 PM UTC-4, m.ce...@gmai= l.com wrote:
<= div>This is a weak argument. We sacrifice the consistency of the operator&l= t;=3D> (works for all types) for doubtful consistency of copy and compar= e (of a single type). We should be fixing language corner cases so it does = what programmer intents.
So I'd rather have operator<=3D&g= t; for arrays in all cases, and fix array copying as well.
<= /blockquote>

Well, here's the thing: most people wil= l not be using `<=3D>` directly. They're going to use the fruits = of `<=3D>`: the implicit generation of the other 2/6 operators in bot= h directions.

So you would need a special rule for= `<=3D>` when applied to arrays saying that they don't gen= erate the other 2/6 operations for them. That would be highly inconsistent.=

If comparison with those operators isn't goin= g to work for language arrays, why should it work for `<=3D>`? At lea= st with it the way it is at present, we can later (after removing the old b= ehavior) change the behavior to work the way we want. Or we can just ditch = language arrays altogether.

--
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-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/75095771-64a6-434c-b9d0-a9d4b1726ce5= %40isocpp.org.
------=_Part_8660_34551546.1529089415147-- ------=_Part_8659_1729467785.1529089415147-- .