220 36970 article Path: news.gmane.org!.POSTED!not-for-mail From: "Arthur O'Dwyer" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Two proposed additions to std::complex Date: Mon, 19 Feb 2018 11:28:37 -0800 Lines: 163 Approved: news@gmane.org Message-ID: References: <91f560ea-5f51-4723-a9d4-4bd1527f1a7d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114011e267e674056595b36b" X-Trace: blaine.gmane.org 1519068404 8654 195.159.176.226 (19 Feb 2018 19:26:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Feb 2018 19:26:44 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBDLZJYWNDQIOPSVM2QCRUBGMFBUD6@isocpp.org Mon Feb 19 20:26:40 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f199.google.com ([209.85.216.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enr58-0001XR-N4 for gclcip-std-proposals@m.gmane.org; Mon, 19 Feb 2018 20:26:34 +0100 Original-Received: by mail-qt0-f199.google.com with SMTP id c25sf9656032qtn.12 for ; Mon, 19 Feb 2018 11:28:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1519068520; cv=pass; d=google.com; s=arc-20160816; b=V2zzDsowM1nA7OzEcV7SB7UaLR6T2JSFmYR6gnLQmCHSxIqsLeTqaExmcg3eJTeib3 b+PihgsJLdcjMQHLDPoI6+Ifrjdt9mz6chaWKzsBIR6bIsbF807JgOwhdElyNwSwGSzV dR32o0GMTQqZlSc5ZBvs53tRDc99EquW+F3D49f4mgZCT/q4rsnV9J60mGv+fCukrvKX yV8/7R7C3KsB17fE6kjoFR9wFpjFFEDb0ReCf8sMnX51KvWldDlMheZwW8RI2nAwLC4m m6AkIn27KrxGaZg8MJz8DqLMcys+SH1TfM1Us5iBe9H1P9A+BsgWtOaSiUuPrzSARYrU 0PUg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=kvsZMUGpSBXB//wPrZ0pvswkdB9SALDswX2FqpUa+EE=; b=iJc0JPy9J428emtpZvePDend3h6KFzP3AgoO+Ja8YpwBtnACBWtvvJExeGtLgqVvqY lrWMaC87Lpej6ynM/YRGQahWUIE3HQFCfBQV5/oJfOeYMc8E5jIu6/22VbdpxSD0QMqk t3sxqcDVkHoPTu9CiTfyc35YD6SP14KUF7BT+hlhn1OSnXscluNGgezrTw/9848YQWhD vE15loqnamI3RiW4A6WJchER3uB6Xat11vw8T7eDzb1R4T7gKR4iazCUlcUUQlrUQp3f VS//MXDFNvFBfF4DC8PdCbFu/H+EoTyt9Y6XzNZH02OtgKefCbk2ZJwftXwJu2ARFnXE soUg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=L9JmNWrX; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=kvsZMUGpSBXB//wPrZ0pvswkdB9SALDswX2FqpUa+EE=; b=NborZPpCFMy6PKcZGM6E56aH6VTX1V5NM1PaUNoiG+i/G9e5MPXmrkm7uImTTo43Wr 9EbCVjQ/Ea0TZs+i5m7g6Mvd9zVaEMZEtO8I7Mu7DJ9WHvY/Rem4yeyfIrjJPv6huAP4 aWfiG86tBTWkUsNrvXaBEkcsY98avJlJUvFLN+NSeWLJXr6qs5uK48YbdaPMZukb+ZJq iETzcuBX/nf8/4WlNFK7CifFocy5ePncxiKp/AA89SpOHAKXEqzVB36SRot50IEwhrWo 8tOuPdGdvBnmR0mk8s74v8P3zroMRKe4V6tz6m2Q77C61R9WJzpboP6Tsgeh4F7TdHc4 pQaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state: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-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=kvsZMUGpSBXB//wPrZ0pvswkdB9SALDswX2FqpUa+EE=; b=Fj7lDDen7Vn+OIXaiVA2oJw3E4DiNZI+Frw6HKzjMi1d2OjgVMXnmD7n4MVyfVcaDC jhxLJGBomkOZvjV0mGEeRNrJx8vba0JUyGBi2gMsTahmoLvFLeLhpH9Tt1jJYrAEoo7f 5GKdp+dgnk/FcnIlRz8CIJYkhspbCmMW91G4xSrX5vsQ9GFsPAxzLwE0WDYcs+z9BzRi FxK3c8uADBSi4tmX7ah7Jz0HE6+feqdZ1+Q2DZZkuqf9pCM82f+hierUTk7rZXf30/zp TV7YWB+RD0eJo1hi5KuyPFYztnhENud78V2QDuXXbbpUoYOqzGsUGM4vfoM6CSh3M2eM 92hQ== X-Gm-Message-State: APf1xPAyIyEfOenDq3Ias9++lW0DVssjahpNzH2n3u0OmhnfQ2Inb9JN akGOa/uoiryUJkYQlJnWWzbP1g== X-Google-Smtp-Source: AH8x226lQrPJvF4aWWD0wWolcGMZGiL2lOGQbZagxVru2FE0g3hKTWM3EFUicWnRM+Xb8Rs85njkwQ== X-Received: by 10.55.27.27 with SMTP id b27mr11831550qkb.53.1519068520640; Mon, 19 Feb 2018 11:28:40 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.55.10.76 with SMTP id 73ls2174978qkk.7.gmail; Mon, 19 Feb 2018 11:28:38 -0800 (PST) X-Received: by 10.55.113.199 with SMTP id m190mr25479905qkc.263.1519068518891; Mon, 19 Feb 2018 11:28:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519068518; cv=none; d=google.com; s=arc-20160816; b=Mek+RLVmTDnV5C1PcsMch3sKRqIm2II9mbiinPoqH4PzdbhkTbhrDa0ucria08/Tp0 zzairLMozd/slOkTzI0BNimBeuGri1gdYskXplKhdAwnwfrPKMzhlJPBIJE3pDVlPazA WWS5scwCE6bhxLlUgUUuY5TMe23z2uniSKQChinbytYBHuj5netwoauMFo4qyVTwlNMe 8oA93tx7WZzbcB9kOWbU05S0kI26GGGsdoRg9eIDDJeZ81vfo1uBuBE/bgMySSo+vJE9 6bcMUkc1I6P3sLR3ueqNyM75Wbzwx+DHIQYw2UyabOzB9CTAw3yGdwQrSnKJ8zWYVs0h 1jtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=Mvw2stC64eHGw8C67W+xS9PlxvJeVShiukR2VJ1AD0s=; b=u2izeT7AI+y83fpoy0JKKHg+sc0Je0Lt1O/pBkmJRVll9HWQ3MdHHe9ZUg/azHnDjO UZSUbIHXILEf8pXUwSi95bkJLNemBZ04a0iMxw52vrfGok4l/aPaF496wKSmBSwVnVUf iaLJa2IcT9grBaV47iwcyMBmJimxumvJ5popwE9mAOSazvkLiYqfajoWFF7e6MtLV9AE feR6ZRV0pKxKmId+2pMWNO8MB743A65Wr9y+ttq++2HR8d6qI1sOlB78CtUoEQXUUWes CpFdhPV8FWpBF3kWQF3SMXcziWQQWA3X3+9D4ZCXaRsLrD0jmhtJ3EMdbUVZbuNDDyzU RRrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=L9JmNWrX; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id r85sor3480063qke.50.2018.02.19.11.28.38 for (Google Transport Security); Mon, 19 Feb 2018 11:28:38 -0800 (PST) Received-SPF: pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.55.20.40 with SMTP id e40mr24539596qkh.66.1519068518014; Mon, 19 Feb 2018 11:28:38 -0800 (PST) Original-Received: by 10.140.90.106 with HTTP; Mon, 19 Feb 2018 11:28:37 -0800 (PST) In-Reply-To: X-Original-Sender: arthur.j.odwyer@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=L9JmNWrX; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:36970 Archived-At: --001a114011e267e674056595b36b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 19, 2018 at 3:25 AM, Giuseppe D'Angelo < giuseppe.dangelo@kdab.com> wrote: > On 19/02/18 07:04, Arthur O'Dwyer wrote: > > > > Structured-binding to a complex number's parts seems like a slam-dunk. > > Unfortunately, not everything that can be structured-binded is > > necessarily "tuple-like". To me it seems wrong to treat "complex number= " > > as a special case of "tuple" throughout your entire codebase. If you're > > asking for the tuple_size of a complex number, you are almost certainly > > doing something wrong, IMO. > > Unfortunately (?), that's the customization point we have to make UDTs > work with structured bindings. So why not using it? > I think we agree on the premises, we just disagree on the appropriate solution. (A) To be achieved: Unpack a complex number into a pair of its real and imaginary parts. (B) If we use structured binding to unpack it, then someone must add specializations of tuple_size etc. in namespace std. (C) If we add specializations of tuple_size etc. in namespace std, then our program will be non-conforming. The OP proposed this solution: (1, for C++2a) We use structured binding to unpack it. ISO (i.e., not-us) adds specializations of tuple_size etc. in namespace std. I proposed two alternative solutions: (2, for C++17) We use structured binding to unpack it. We add specializations of tuple_size etc. in namespace std. Our program becomes non-conforming. (3, for C++11) We unpack it without using structured binding. I think (3) is far and away the best solution. > (Yes, I agree on the general principle, asking for the tuple_size of an arbitrary "Employee" class seems weird.) Also agreed. Personally I think that "Complex Number" is much closer to "Employee" than to "Tuple". Or anyway, there are a certain set of operations I would naturally expect to be provided for "Complex Numbers", such as operator+ and operator*; and there are a certain set of operations I would expect *not* to be provided, such as .salary() and .size(); and then there's this operation tuple_size, which I personally also put in the "expect *not* to be provided" category. We have to be particularly careful about adding new general-purpose operations to library types in C++ because of SFINAE; and I expect that in C++2a we'll have to be even more careful, because of Concepts. Concepts fundamentally encourage library programming based on syntactic constraints =E2=80=94 "looks like a tuple, so let's just assume it walks and quacks lik= e a tuple." So unless it really *does* quack like a tuple, you'd darn well better *not* make it *look* like a tuple. Arthur P.S. =E2=80=94 If this idea does move forward, you should consider whether = you want this to work, and if so, how: auto& [x, y] =3D z; x =3D 42; I'm not saying it's hard to make it work; just that you ought to discuss the pros and cons in whatever proposal might come out of this. --=20 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 e= mail 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/CADvuK0JEQfY_9mwRyZM%2B8UP5RqB2wkfqYqkO_Egfx1FLi= sG%3D%3Dw%40mail.gmail.com. --001a114011e267e674056595b36b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Feb 19, 2018 at 3:25 AM, Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> wrote:
On 19/02/18 07:04, Arthur O'Dwyer wrote:
>
> Structured-binding to a complex number's parts seems like a slam-d= unk.
> Unfortunately, not everything that can be structured-binded is
> necessarily "tuple-like". To me it seems wrong to treat &quo= t;complex number"
> as a special case of "tuple" throughout your entire codebase= .. If you're
> asking for the tuple_size of a complex number, you are almost certainl= y
> doing something wrong, IMO.

Unfortunately (?), that's the customization point we have to mak= e UDTs
work with structured bindings. So why not using it?=C2=A0

I think we agree on the pr= emises, we just disagree on the appropriate solution.
(A) To be a= chieved: Unpack a complex number into a pair<R,R> of its real and ima= ginary parts.
(B) If we use structured binding to unpack it, then= someone must add specializations of tuple_size etc. in namespace std.
(C) If we add specializations of tuple_size etc. in namespace std, th= en our program will be non-conforming.
The OP proposed this solut= ion:
(1, for C++2a) We use structured binding to unpack it. ISO (= i.e., not-us) adds specializations of tuple_size etc. in namespace std.
I proposed two alternative solutions:
(2, for C++17) We us= e structured binding to unpack it. We add specializations of tuple_size etc= .. in namespace std. Our program becomes non-conforming.
(3, for C= ++11) We unpack it without using structured binding.

I think (3) is far and away the best solution.

=
> (Yes, I agree on the=C2=A0general principle, asking for= the tuple_size of an arbitrary "Employee"=C2=A0class seems weird= ..)

Also agreed. Personally I think that "= Complex Number" is much closer to "Employee" than to "T= uple". Or anyway, there are a certain set of operations I would natura= lly expect to be provided for "Complex Numbers", such as operator= + and operator*; and there are a certain set of operations I would expect <= i>not to be provided, such as .salary() and .size(); and then there'= ;s this operation tuple_size, which I personally also put in the "expe= ct not to be provided" category.

We ha= ve to be particularly careful about adding new general-purpose operations t= o library types in C++ because of SFINAE; and I expect that in C++2a we'= ;ll have to be even more careful, because of Concepts. Concepts fundamental= ly encourage library programming based on syntactic constraints =E2=80=94 &= quot;looks like a tuple, so let's just assume it walks and quacks like = a tuple." So unless it really does quack like a tuple, you'= d darn well better not make it look like a tuple.
<= br>
Arthur

P.S. =E2=80=94 If this idea d= oes move forward, you should consider whether you want this to work, and if= so, how:
=C2=A0 =C2=A0 auto& [x, y] =3D z;
=C2=A0 = =C2=A0 x =3D 42;
I'm not saying it's hard to make it work= ; just that you ought to discuss the pros and cons in whatever proposal mig= ht come out of this.

--
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/CADvuK0JEQf= Y_9mwRyZM%2B8UP5RqB2wkfqYqkO_Egfx1FLisG%3D%3Dw%40mail.gmail.com.
--001a114011e267e674056595b36b-- .