220 36962 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: Sun, 18 Feb 2018 22:04:00 -0800 (PST) Lines: 200 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/mixed; boundary="----=_Part_11409_831412584.1519020240839" X-Trace: blaine.gmane.org 1519020150 20952 195.159.176.226 (19 Feb 2018 06:02:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Feb 2018 06:02:30 +0000 (UTC) Cc: zy@miator.net To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQINDUNJ2QCRUBCYWY4HI@isocpp.org Mon Feb 19 07:02:25 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eneWT-0003Qi-3t for gclcip-std-proposals@m.gmane.org; Mon, 19 Feb 2018 07:01:57 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id r4sf4457491vke.17 for ; Sun, 18 Feb 2018 22:04:03 -0800 (PST) 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=b/zTAjm2Sq53UAMU/YmDERTbk6V89lD5+vq2XPvo0XI=; b=lr/JyYhWzjk7iYh4tSqrZJdScmqlTU3A0zHcHGbmccVntBFKzdh6ErSUvMsY+MlfUO aUS6bTl55QZSaV0GZ4LzSBmDrJxFTZcFXQ7m2rOSku0ZlRTqEjGmxLlzX8Z2+Um254Y2 8/z7b+OAqInzBEvAZQSgTttn/H+3oOrmJABjFQjYitIwzYkHQwa+iEnB3mev4MGDCJ76 BZa8kqFIBUmC/1mrsosdGIT4sVh7XOooaIJOalJfv09vEVue9nIJcxXOZ2S9EyHbJald d0T7NuVl94b1WDD0yXOKd8Pm6leE7YDVddufhy5z3+fIgr9v94UcFxR5Keg6AoQZu5hc lhdw== 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=b/zTAjm2Sq53UAMU/YmDERTbk6V89lD5+vq2XPvo0XI=; b=T6FyCVy7opMMQ4rlIQ33ar7rcFpGSLG/Rn09tjd3/ChHHUWg01MjIuXnE3UiV2EstW CSdSv3BZVLitai4KWW36pHgHSl8ds/Xk1Q0syc3Jm6IAUTDmM7sj4oEO88Q1loubKVA+ +8Y71W30uIykG666QOMNG7p1G5RgDZR9ebkk3HT+c5jdwQelbnys4X4SWK9+Y3FbW+cm aMoTwsmZA/MTs7Qu+8KdBrrFrl2KI4d7eMfcYbk4zhWbuQ/LLLX55gsoaGSRrH/KDosp OeTrAH3QjrWbhJbMhIv7kGjBAzKY28lnForR5unhBaSJ4lOYlfhH9YrjDdqJfdkFqgdR rKRA== 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=b/zTAjm2Sq53UAMU/YmDERTbk6V89lD5+vq2XPvo0XI=; b=IlguMzxcEBhzinCIbxeqFISEb8khkr/eoLICjatCTGS6x0iYTQvJjSvgg4GYM0uTh0 SzRbzQk3rH9d0tha4l33ozFaTpWu+xivPX5utGrMIHhS3Y82BpKpRmBZdC1YWD2gSLVj Lbf3q64zVDk7L1Du4jnZjcNEwX/1uv3MUtv7AA485oPcIIWx1hmO/FLQa/9JCe6KCWMM 505EZPht/fc0/YDnNca/8FiRGeWJp0Hgnva6164sP24kTLe9PHxjCk77uE9tFrQkCLaV DetswHFIDPQ29b9nT8nO23Kv0D14KqVmkvw1fCUF1XX3c1/RcSqrRa1yX40RRgqd+vmS QvwQ== X-Gm-Message-State: APf1xPDmDGilTfaxRPZhPICHVqOBYGC40sbNPMeRjtd3EbZ2dUckl3fc QUos2m/aanGqdAh/t7E5U/TEQQ== X-Google-Smtp-Source: AH8x226ifpFrbbyr7b5vfOp8fPTMvIXAU1S/b78EZDTHxubus8EHCMtrmDx7xb1KrDfZtRGBjwmSpg== X-Received: by 10.176.21.175 with SMTP id i44mr7286363uae.15.1519020243208; Sun, 18 Feb 2018 22:04:03 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.11.76 with SMTP id 73ls3927825vkl.1.gmail; Sun, 18 Feb 2018 22:04:01 -0800 (PST) X-Received: by 10.31.169.23 with SMTP id s23mr2047245vke.1.1519020241304; Sun, 18 Feb 2018 22:04:01 -0800 (PST) In-Reply-To: X-Original-Sender: arthur.j.odwyer@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:36962 Archived-At: ------=_Part_11409_831412584.1519020240839 Content-Type: multipart/alternative; boundary="----=_Part_11410_1274874.1519020240839" ------=_Part_11410_1274874.1519020240839 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sunday, February 18, 2018 at 1:39:30 PM UTC-8, Richard Smith wrote: > > On 18 February 2018 at 08:47, Alberto Barbati > wrote: > >> Il giorno sabato 17 febbraio 2018 08:51:08 UTC+1, Zhihao Yuan ha scritto= : >>> >>> While it makes sense, why z[0] and z.size() rather than >>> get<0>(z) and tuple_size_v? >>> >> >> +1, that would allow structured bindings with std::complex, which would= =20 >> be nice to have: >> >> void f(std::complex c) >> { >> auto [re, im] =3D c; >> // ... >> } >> >> does anyone know if it has ever been considered and, if yes, why we don'= t=20 >> already have it? >> > > FWIW, this seemed sufficiently obvious when I was implementing structured= =20 > bindings in Clang that our built-in complex number support (C99's _Comple= x)=20 > natively supports structured bindings: https://godbolt.org/g/DRVNrX=20 > Structured-binding to a complex number's parts seems like a slam-dunk.=20 Unfortunately, not everything that can be structured-binded is necessarily= =20 "tuple-like". To me it seems wrong to treat "complex number" as a special= =20 case of "tuple" throughout your entire codebase. If you're asking for the= =20 tuple_size of a complex number, you are almost certainly doing something=20 wrong, IMO. What you probably want is more like a customization point for= =20 some specific algorithm where you can say "*for the purposes of this=20 algorithm*, here's how you convert a T into a pair". You can already force structured-binding to treat std::complex values as=20 pairs, if that's what you really want to do. It's super cumbersome and easy= =20 to get wrong, like everything about structured bindings, but it's *possible= *.=20 Here's the code: https://godbolt.org/g/iPWgkW But for your purposes, Nick, I strongly suggest that *you would not benefit= *=20 from throwing away the type-safety benefits that come from treating complex= =20 numbers as *numbers* rather than as raw pairs. If you have a particular=20 generic algorithm that could work with any T decomposable into a pair of=20 Rs, then you should do something like this: https://godbolt.org/g/GhQMzi Passing in the decomposition function as a parameter to the algorithm is=20 better because it's more generic; the benefit is that you'll be able to use= =20 the same generic algorithm with other types in the future, if necessary,=20 rather than baking in a hard dependency on the number of public fields in= =20 the struct, or whatever. (You can even reuse the same algorithm to compute= =20 the foo of the complex conjugate of x with just a trivial change to the=20 lambda! Can't do that with raw struct access.) Parameterizing your *algorithm* is often a better solution than=20 manipulating your *type definitions* to conform to some or another concept= =20 that they might actually not be a very good match for. =E2=80=93Arthur --=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/db59580b-7cec-41ec-b4cd-e71a8fddaeb6%40isocpp.or= g. ------=_Part_11410_1274874.1519020240839 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, February 18, 2018 at 1:39:30 PM UTC-8, Richard = Smith wrote:
<= div>
On 18 February 2018 at 08:47, Alberto Barbat= i <alberto...@gmail.com> wrote:
Il giorno sa= bato 17 febbraio 2018 08:51:08 UTC+1, Zhihao Yuan ha scritto:
While it makes sense, why z[0] and= z.size() rather than
get<0>(z) and tuple_size_v<com= plex>?

+1, that would allow structured= bindings with std::complex, which would be nice to have:

void f(std::comp= lex<double> c)
{
=C2=A0 =C2=A0 = auto [re, im]= =3D c;
=C2= =A0 =C2=A0 // ...
}

does anyone know if it has ever been considered= and, if yes, why we don't already have it?

FWIW, this seemed sufficiently obvious when I was implemen= ting structured bindings in Clang that our built-in complex number support = (C99's _Complex) natively supports structured bindings:=C2=A0https:= //godbolt.org/g/DRVNrX=C2=A0
<= div>
Structured-binding to a complex number's parts seems= like a slam-dunk. Unfortunately, not everything that can be structured-bin= ded is necessarily "tuple-like". To me it seems wrong to treat &q= uot;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. =C2=A0What you= probably want is more like a customization point for some specific algorit= hm where you can say "for the purposes of this algorithm, here&= #39;s how you convert a T into a pair<R,R>".

You can already force structured-binding to treat std::complex values= as pairs, if that's what you really want to do. It's super cumbers= ome and easy to get wrong, like everything about structured bindings, but i= t's possible. Here's the code:

But for your purposes, Nick, I strongly suggest that you would = not benefit from throwing away the type-safety benefits that come from = treating complex numbers as numbers rather than as raw pairs. If you= have a particular generic algorithm that could work with any T decomposabl= e into a pair of Rs, then you should do something like this:
https://godbolt.org/g/GhQMzi
Passing in the decomposition function as a parameter to the algori= thm is better because it's more generic; the benefit is that you'll= be able to use the same generic algorithm with other types in the future, = if necessary, rather than baking in a hard dependency on the number of publ= ic fields in the struct, or whatever. (You can even reuse the same algorith= m to compute the foo of the complex conjugate of x with just a trivial chan= ge to the lambda! Can't do that with raw struct access.)
Para= meterizing your algorithm is often a better solution than manipulati= ng your type definitions to conform to some or another concept that = they might actually not be a very good match for.

= =E2=80=93Arthur

--
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/db59580b-7cec-41ec-b4cd-e71a8fddaeb6= %40isocpp.org.
------=_Part_11410_1274874.1519020240839-- ------=_Part_11409_831412584.1519020240839-- .