Topic: Two proposed additions to std::complex
Author: "nthompson via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 16 Feb 2018 19:22:41 -0800 (PST)
Raw View
------=_Part_5338_254184364.1518837761955
Content-Type: multipart/alternative;
boundary="----=_Part_5339_827328237.1518837761956"
------=_Part_5339_827328237.1518837761956
Content-Type: text/plain; charset="UTF-8"
I would like to propose two additions to std::complex:
1) The free function std::size, which is defined on std::vector and
std::array in C++17, should also be defined for std::complex, and return 2.
2) If z is of type std::complex<Real>, then z[0] should return the real
part, and z[1] should return the imaginary part of z.
What is the use case? These additions make manifest the isomorphism (as
vector spaces) of C and R^2. This would allow me to write a
'vector_trapezoidal' quadrature that worked for integrands from R->R^k, and
R->C. The trapezoidal quadrature of R->C is especially important, as it
affords and exponentially convergent scheme to evaluate special functions
on the complex plane via contour integration, and gives us a numerically
stable way to take arbitrarily high derivatives (ala Lyness and Moler). In
addition, it would allow us to treat a std::complex as a generic geometric
point in R^2. This would allow use to compute plane curves using complex
methods, and then interpolate them using (say) Catmull Rom. This could be
useful for an SVG renderer or planar video games.
Thanks,
Nick Thompson
--
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/d0de64ba-0be2-4248-8e51-46e35901bb2e%40isocpp.org.
------=_Part_5339_827328237.1518837761956
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I would like to propose two additions to std::complex:<div=
><br></div><div>1) The free function std::size, which is defined on std::ve=
ctor and std::array in C++17, should also be defined for std::complex, and =
return 2.</div><div>2) If z is of type std::complex<Real>, then z[0] =
should return the real part, and z[1] should return the imaginary part of z=
..</div><div><br></div><div>What is the use case? These additions make manif=
est the isomorphism (as vector spaces) of C and R^2. This would allow me to=
write a 'vector_trapezoidal' quadrature that worked for integrands=
from R->R^k, and R->C. The trapezoidal quadrature of R->C is espe=
cially important, as it affords and exponentially convergent scheme to eval=
uate special functions on the complex plane via contour integration, and gi=
ves us a numerically stable way to take arbitrarily high derivatives (ala L=
yness and Moler). In addition, it would allow us to treat a std::complex as=
a generic geometric point in R^2. This would allow use to compute plane cu=
rves using complex methods, and then interpolate them using (say) Catmull R=
om. This could be useful for an SVG renderer or planar video games.</div><d=
iv><br></div><div><br></div><div>=C2=A0 Thanks,</div><div><br></div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0Nick Thompson</div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d0de64ba-0be2-4248-8e51-46e35901bb2e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d0de64ba-0be2-4248-8e51-46e35901bb2e=
%40isocpp.org</a>.<br />
------=_Part_5339_827328237.1518837761956--
------=_Part_5338_254184364.1518837761955--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Sat, 17 Feb 2018 02:51:01 -0500
Raw View
This is a multi-part message in MIME format.
--b1_847178e4bcdb2fdc84dfa8c7e6f039b7
Content-Type: text/plain; charset="UTF-8"
While it makes sense, why z[0] and z.size() rather than
get<0>(z) and tuple_size_v<complex>?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
On February 17, 2018 11:22 AM, nthompson via ISO C++ Standard - Future Proposals <std-proposals@isocpp.org> wrote:
> I would like to propose two additions to std::complex:
>
> 1) The free function std::size, which is defined on std::vector and std::array in C++17, should also be defined for std::complex, and return 2.
> 2) If z is of type std::complex<Real>, then z[0] should return the real part, and z[1] should return the imaginary part of z.
--
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/D6NTUMcPbfoSWbtXdUsmWOfdOouYXqpt-YRUh_nbxYA6O1ffW5q876wjKgjY5QgEWcIkcLWAw5gSm8CJAeO6icr_S3EMe5WoZp2vyP3F0iA%3D%40miator.net.
--b1_847178e4bcdb2fdc84dfa8c7e6f039b7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div>While it makes sense, why z[0] and z.size() rather than<br></div><div>=
get<0>(z) and tuple_size_v<complex>?</div><div><br></div><div c=
lass=3D"protonmail_signature_block"><div class=3D"protonmail_signature_bloc=
k-user"><div>--<br></div><div><span>Zhihao Yuan, ID lichray<br>The best way=
to predict the future is to invent it.<br>________________________________=
_______________</span></div></div><div class=3D"protonmail_signature_block-=
proton protonmail_signature_block-empty"><br></div></div><div><br></div><di=
v>On February 17, 2018 11:22 AM, nthompson via ISO C++ Standard - Future Pr=
oposals <std-proposals@isocpp.org> wrote:<br></div><div> <br></div><b=
lockquote class=3D"protonmail_quote" type=3D"cite"><div dir=3D"ltr"><div>I =
would like to propose two additions to std::complex:<br></div><div><br></di=
v><div>1) The free function std::size, which is defined on std::vector and =
std::array in C++17, should also be defined for std::complex, and return 2.=
<br></div><div>2) If z is of type std::complex<Real>, then z[0] shoul=
d return the real part, and z[1] should return the imaginary part of z.<br>=
</div></div></blockquote><div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/D6NTUMcPbfoSWbtXdUsmWOfdOouYXqpt-YRUh=
_nbxYA6O1ffW5q876wjKgjY5QgEWcIkcLWAw5gSm8CJAeO6icr_S3EMe5WoZp2vyP3F0iA%3D%4=
0miator.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/D6NTUMcPbfoSWbtXdUsmWOfdOouYXqpt-YRUh=
_nbxYA6O1ffW5q876wjKgjY5QgEWcIkcLWAw5gSm8CJAeO6icr_S3EMe5WoZp2vyP3F0iA%3D%4=
0miator.net</a>.<br />
--b1_847178e4bcdb2fdc84dfa8c7e6f039b7--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Sat, 17 Feb 2018 09:35:39 +0000
Raw View
--001a113ed2b82799580565652f7c
Content-Type: text/plain; charset="UTF-8"
On 17 Feb 2018 8:51 am, "Zhihao Yuan" <zy@miator.net> wrote:
While it makes sense, why z[0] and z.size() rather than
get<0>(z) and tuple_size_v<complex>?
Why not both?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
On February 17, 2018 11:22 AM, nthompson via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
I would like to propose two additions to std::complex:
1) The free function std::size, which is defined on std::vector and
std::array in C++17, should also be defined for std::complex, and return 2.
2) If z is of type std::complex<Real>, then z[0] should return the real
part, and z[1] should return the imaginary part of z.
--
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/D6NTUMcPbfoSWbtXdUsmWOfdOouYXqpt-YRUh_
nbxYA6O1ffW5q876wjKgjY5QgEWcIkcLWAw5gSm8CJAeO6icr_S3EMe5WoZp2vyP3F0iA%3D%
40miator.net
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/D6NTUMcPbfoSWbtXdUsmWOfdOouYXqpt-YRUh_nbxYA6O1ffW5q876wjKgjY5QgEWcIkcLWAw5gSm8CJAeO6icr_S3EMe5WoZp2vyP3F0iA%3D%40miator.net?utm_medium=email&utm_source=footer>
..
--
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/CALvx3hZRYDq4CbEyfUq29jyXdzHDRD_ndZiw7cn-dhLpXbWcUQ%40mail.gmail.com.
--001a113ed2b82799580565652f7c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 17 Feb 2018 8:51 am, "Zhihao Yuan" <<a href=3D"ma=
ilto:zy@miator.net">zy@miator.net</a>> wrote:<br type=3D"attribution"><b=
lockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div>While it makes sense, why z[0] and z.size() rat=
her than<br></div><div>get<0>(z) and tuple_size_v<complex>?</di=
v><div></div></blockquote></div></div></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">Why not both?=C2=A0</div><div dir=3D"auto"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></di=
v><div class=3D"m_2965287843203900071protonmail_signature_block"><div class=
=3D"m_2965287843203900071protonmail_signature_block-user"><div>--<br></div>=
<div><span>Zhihao Yuan, ID lichray<br>The best way to predict the future is=
to invent it.<br>______________________________<wbr>_________________</spa=
n></div></div><div class=3D"m_2965287843203900071protonmail_signature_block=
-proton m_2965287843203900071protonmail_signature_block-empty"><br></div></=
div><div class=3D"quoted-text"><div><br></div><div>On February 17, 2018 11:=
22 AM, nthompson via ISO C++ Standard - Future Proposals <<a href=3D"mai=
lto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a=
>> wrote:<br></div><div> <br></div><blockquote class=3D"m_29652878432039=
00071protonmail_quote" type=3D"cite"><div dir=3D"ltr"><div>I would like to =
propose two additions to std::complex:<br></div><div><br></div><div>1) The =
free function std::size, which is defined on std::vector and std::array in =
C++17, should also be defined for std::complex, and return 2.<br></div><div=
>2) If z is of type std::complex<Real>, then z[0] should return the r=
eal part, and z[1] should return the imaginary part of z.<br></div></div></=
blockquote><div><br></div>
<p></p></div><div class=3D"quoted-text">
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/D6NTUMcPbfoSWbtXdUsmWOfdOouYXqpt-YRUh=
_nbxYA6O1ffW5q876wjKgjY5QgEWcIkcLWAw5gSm8CJAeO6icr_S3EMe5WoZp2vyP3F0iA%3D%4=
0miator.net?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">h=
ttps://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/<wbr>=
D6NTUMcPbfoSWbtXdUsmWOfdOouYXq<wbr>pt-YRUh_<wbr>nbxYA6O1ffW5q876wjKgjY5QgEW=
cIk<wbr>cLWAw5gSm8CJAeO6icr_<wbr>S3EMe5WoZp2vyP3F0iA%3D%<wbr>40miator.net</=
a>.<br>
</blockquote></div><br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZRYDq4CbEyfUq29jyXdzHDRD_ndZiw=
7cn-dhLpXbWcUQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZRYDq4CbEy=
fUq29jyXdzHDRD_ndZiw7cn-dhLpXbWcUQ%40mail.gmail.com</a>.<br />
--001a113ed2b82799580565652f7c--
.
Author: "nthompson via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sun, 18 Feb 2018 10:31:35 -0800 (PST)
Raw View
------=_Part_9200_158626348.1518978695688
Content-Type: multipart/alternative;
boundary="----=_Part_9201_1583990804.1518978695688"
------=_Part_9201_1583990804.1518978695688
Content-Type: text/plain; charset="UTF-8"
I think that it depends on your mental model. z[0] and z.size() are more
appropriate if you regard a complex number as a special case of a vector in
R^k and want your templated algorithms to work for vectors and complex
numbers, but as others have commented, the tuple syntax seems to be useful
as well.
On Saturday, February 17, 2018 at 1:51:08 AM UTC-6, Zhihao Yuan wrote:
>
> While it makes sense, why z[0] and z.size() rather than
> get<0>(z) and tuple_size_v<complex>?
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
>
>
> On February 17, 2018 11:22 AM, nthompson via ISO C++ Standard - Future
> Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
> I would like to propose two additions to std::complex:
>
> 1) The free function std::size, which is defined on std::vector and
> std::array in C++17, should also be defined for std::complex, and return 2.
> 2) If z is of type std::complex<Real>, then z[0] should return the real
> part, and z[1] should return the imaginary part of z.
>
>
>
--
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/78d83082-81f7-4d1c-a378-661fa9715672%40isocpp.org.
------=_Part_9201_1583990804.1518978695688
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think that it depends on your mental model. z[0] and z.s=
ize() are more appropriate if you regard a complex number as a special case=
of a vector in R^k and want your templated algorithms to work for vectors =
and complex numbers, but as others have commented, the tuple syntax seems t=
o be useful as well.<br><br>On Saturday, February 17, 2018 at 1:51:08 AM UT=
C-6, Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Wh=
ile it makes sense, why z[0] and z.size() rather than<br></div><div>get<=
0>(z) and tuple_size_v<complex>?</div><div><br></div><div><div><di=
v>--<br></div><div><span>Zhihao Yuan, ID lichray<br>The best way to predict=
the future is to invent it.<br>______________________________<wbr>________=
_________</span></div></div><div><br></div></div><div><br></div><div>On Feb=
ruary 17, 2018 11:22 AM, nthompson via ISO C++ Standard - Future Proposals =
<<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"fdP_=
CItKBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>> wrote:<br></div><div> <br></div><blockquote typ=
e=3D"cite"><div dir=3D"ltr"><div>I would like to propose two additions to s=
td::complex:<br></div><div><br></div><div>1) The free function std::size, w=
hich is defined on std::vector and std::array in C++17, should also be defi=
ned for std::complex, and return 2.<br></div><div>2) If z is of type std::c=
omplex<Real>, then z[0] should return the real part, and z[1] should =
return the imaginary part of z.<br></div></div></blockquote><div><br></div>=
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/78d83082-81f7-4d1c-a378-661fa9715672%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/78d83082-81f7-4d1c-a378-661fa9715672=
%40isocpp.org</a>.<br />
------=_Part_9201_1583990804.1518978695688--
------=_Part_9200_158626348.1518978695688--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 18 Feb 2018 13:39:04 -0800
Raw View
--001a114821544a809405658369b8
Content-Type: text/plain; charset="UTF-8"
On 18 February 2018 at 08:47, Alberto Barbati <albertobarbati@gmail.com>
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<complex>?
>>
>>
> +1, that would allow structured bindings with std::complex, which would be
> nice to have:
>
> void f(std::complex<double> c)
> {
> auto [re, im] = c;
> // ...
> }
>
> 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 implementing structured
bindings in Clang that our built-in complex number support (C99's _Complex)
natively supports structured bindings: https://godbolt.org/g/DRVNrX
--
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/CAOfiQqmQUx1%3DL2ZMLB0W6mE5TE9mK8jyrFoh9yugJDN02bzNDA%40mail.gmail.com.
--001a114821544a809405658369b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
8 February 2018 at 08:47, Alberto Barbati <span dir=3D"ltr"><<a href=3D"=
mailto:albertobarbati@gmail.com" target=3D"_blank">albertobarbati@gmail.com=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr"><span class=3D"gmail-">Il giorno sabato 17 febbraio 2018 =
08:51:08 UTC+1, Zhihao Yuan ha scritto:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div>While it makes sense, why z[0] and z.size() rather than<=
br></div><div>get<0>(z) and tuple_size_v<complex>?</div><br></b=
lockquote></span><div><br>+1, that would allow structured bindings with std=
::complex, which would be nice to have:<br><br><div style=3D"background-col=
or:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border=
-width:1px" class=3D"gmail-m_-7701676839095844052prettyprint"><code class=
=3D"gmail-m_-7701676839095844052prettyprint"><div class=3D"gmail-m_-7701676=
839095844052subprettyprint"><span style=3D"color:rgb(0,0,136)" class=3D"gma=
il-m_-7701676839095844052styled-by-prettify">void</span><span style=3D"colo=
r:rgb(0,0,0)" class=3D"gmail-m_-7701676839095844052styled-by-prettify"> f</=
span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-770167683909584=
4052styled-by-prettify">(</span><span style=3D"color:rgb(0,0,0)" class=3D"g=
mail-m_-7701676839095844052styled-by-prettify">std</span><span style=3D"col=
or:rgb(102,102,0)" class=3D"gmail-m_-7701676839095844052styled-by-prettify"=
>::</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-77016768390958=
44052styled-by-prettify">complex</span><span style=3D"color:rgb(0,136,0)" c=
lass=3D"gmail-m_-7701676839095844052styled-by-prettify"><double></spa=
n><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7701676839095844052sty=
led-by-prettify"> c</span><span style=3D"color:rgb(102,102,0)" class=3D"gma=
il-m_-7701676839095844052styled-by-prettify">)</span><span style=3D"color:r=
gb(0,0,0)" class=3D"gmail-m_-7701676839095844052styled-by-prettify"><br></s=
pan><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7701676839095844=
052styled-by-prettify">{</span><span style=3D"color:rgb(0,0,0)" class=3D"gm=
ail-m_-7701676839095844052styled-by-prettify"><br>=C2=A0 =C2=A0 </span><spa=
n style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-7701676839095844052styled-=
by-prettify">auto</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-=
7701676839095844052styled-by-prettify"> </span><span style=3D"color:rgb(102=
,102,0)" class=3D"gmail-m_-7701676839095844052styled-by-prettify">[</span><=
span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7701676839095844052styled=
-by-prettify">re</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-=
m_-7701676839095844052styled-by-prettify">,</span><span style=3D"color:rgb(=
0,0,0)" class=3D"gmail-m_-7701676839095844052styled-by-prettify"> im</span>=
<span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7701676839095844052s=
tyled-by-prettify">]</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-=
m_-7701676839095844052styled-by-prettify"> </span><span style=3D"color:rgb(=
102,102,0)" class=3D"gmail-m_-7701676839095844052styled-by-prettify">=3D</s=
pan><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7701676839095844052s=
tyled-by-prettify"> c</span><span style=3D"color:rgb(102,102,0)" class=3D"g=
mail-m_-7701676839095844052styled-by-prettify">;</span><span style=3D"color=
:rgb(0,0,0)" class=3D"gmail-m_-7701676839095844052styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)" class=3D"gmail-m_-7=
701676839095844052styled-by-prettify">// ...</span><span style=3D"color:rgb=
(0,0,0)" class=3D"gmail-m_-7701676839095844052styled-by-prettify"><br></spa=
n><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-770167683909584405=
2styled-by-prettify">}</span></div></code></div><br>does anyone know if it =
has ever been considered and, if yes, why we don't already have it?</di=
v></div></blockquote><div><br></div><div>FWIW, this seemed sufficiently obv=
ious when I was implementing structured bindings in Clang that our built-in=
complex number support (C99's _Complex) natively supports structured b=
indings:=C2=A0<a href=3D"https://godbolt.org/g/DRVNrX">https://godbolt.org/=
g/DRVNrX</a>=C2=A0</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmQUx1%3DL2ZMLB0W6mE5TE9mK8jyrF=
oh9yugJDN02bzNDA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmQUx1%3D=
L2ZMLB0W6mE5TE9mK8jyrFoh9yugJDN02bzNDA%40mail.gmail.com</a>.<br />
--001a114821544a809405658369b8--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sun, 18 Feb 2018 22:04:00 -0800 (PST)
Raw View
------=_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 <alberto...@gmail.com=20
> <javascript:>> 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<complex>?
>>>
>>
>> +1, that would allow structured bindings with std::complex, which would=
=20
>> be nice to have:
>>
>> void f(std::complex<double> 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<R,R>".
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
<div dir=3D"ltr">On Sunday, February 18, 2018 at 1:39:30 PM UTC-8, Richard =
Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote">On 18 February 2018 at 08:47, Alberto Barbat=
i <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"Q6sG4FPGBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&=
#39;;return true;">alberto...@gmail.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span>Il giorno sa=
bato 17 febbraio 2018 08:51:08 UTC+1, Zhihao Yuan ha scritto:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex"><div>While it makes sense, why z[0] and=
z.size() rather than<br></div><div>get<0>(z) and tuple_size_v<com=
plex>?</div></blockquote></span><div><br>+1, that would allow structured=
bindings with std::complex, which would be nice to have:<br><br><div style=
=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-=
style:solid;border-width:1px"><code><div><span style=3D"color:rgb(0,0,136)"=
>void</span><span style=3D"color:rgb(0,0,0)"> f</span><span style=3D"color:=
rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">std</span><span st=
yle=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">comp=
lex</span><span style=3D"color:rgb(0,136,0)"><double></span><span sty=
le=3D"color:rgb(0,0,0)"> c</span><span style=3D"color:rgb(102,102,0)">)</sp=
an><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102=
,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span>=
<span style=3D"color:rgb(0,0,136)">auto</span><span style=3D"color:rgb(0,0,=
0)"> </span><span style=3D"color:rgb(102,102,0)">[</span><span style=3D"col=
or:rgb(0,0,0)">re</span><span style=3D"color:rgb(102,102,0)">,</span><span =
style=3D"color:rgb(0,0,0)"> im</span><span style=3D"color:rgb(102,102,0)">]=
</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(10=
2,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> c</span><span style=
=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)">// ...</span><span sty=
le=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">}</=
span></div></code></div><br>does anyone know if it has ever been considered=
and, if yes, why we don't already have it?</div></div></blockquote><di=
v><br></div><div>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=A0<a href=3D=
"https://godbolt.org/g/DRVNrX" target=3D"_blank" rel=3D"nofollow" onmousedo=
wn=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbol=
t.org%2Fg%2FDRVNrX\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFzvfqiO_JhHhEbUe=
9weFfXePOpJQ';return true;" onclick=3D"this.href=3D'https://www.goo=
gle.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FDRVNrX\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNFzvfqiO_JhHhEbUe9weFfXePOpJQ';return true;">https:=
//godbolt.org/<wbr>g/DRVNrX</a>=C2=A0</div></div></div></div></blockquote><=
div><br></div><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 "<i>for the purposes of this algorithm</i>, here&=
#39;s how you convert a T into a pair<R,R>".</div><div><br></div=
><div>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 <i>possible</i>. Here's the code:</div><div><a href=3D"https://=
godbolt.org/g/iPWgkW">https://godbolt.org/g/iPWgkW</a><br></div><div><br></=
div><div>But for your purposes, Nick, I strongly suggest that <i>you would =
not benefit</i> from throwing away the type-safety benefits that come from =
treating complex numbers as <i>numbers</i> 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:</div><div><a h=
ref=3D"https://godbolt.org/g/GhQMzi">https://godbolt.org/g/GhQMzi</a><br></=
div><div>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.)</div><div>Para=
meterizing your <i>algorithm</i> is often a better solution than manipulati=
ng your <i>type definitions</i> to conform to some or another concept that =
they might actually not be a very good match for.</div><div><br></div><div>=
=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/db59580b-7cec-41ec-b4cd-e71a8fddaeb6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/db59580b-7cec-41ec-b4cd-e71a8fddaeb6=
%40isocpp.org</a>.<br />
------=_Part_11410_1274874.1519020240839--
------=_Part_11409_831412584.1519020240839--
.
Author: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Date: Mon, 19 Feb 2018 12:25:39 +0100
Raw View
This is a cryptographically signed message in MIME format.
--------------ms000700020803040602090300
Content-Type: text/plain; charset="UTF-8"
Content-Language: en-GB
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? (Yes, I agree on the
general principle, asking for the tuple_size of an arbitrary "Employee"
class seems weird.)
> 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 cumbersome and easy to get wrong, like everything about structured bindings, but it's possible.
But you can't add specializations in namespace std for non-UDTs...?
Cheers,
--
Giuseppe D'Angelo | giuseppe.dangelo@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
--
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/a17826dc-6414-2ebf-f224-f056b00ec30d%40kdab.com.
--------------ms000700020803040602090300
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CyQwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggZtMIIFVaADAgECAhBFV52OgCPAMZmqkvaDgfOpMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTYwNTIwMDAwMDAwWhcNMTkwNTIwMjM1OTU5WjCCAWIxCzAJBgNVBAYTAlNF
MQ8wDQYDVQQREwY2ODMgMzExEjAQBgNVBAgTCVZhZXJtbGFuZDEQMA4GA1UEBxMHSGFnZm9y
czEYMBYGA1UECRMPTm9ycmluZ3MgdmFlZyAyMQ8wDQYDVQQSEwZCb3ggMzAxJjAkBgNVBAoM
HUtsYXLDpGx2ZGFsZW5zIERhdGFrb25zdWx0IEFCMR0wGwYDVQQLExRBIEtEQUIgR3JvdXAg
Q29tcGFueTFDMEEGA1UECww6SXNzdWVkIHRocm91Z2ggS2xhcsOkbHZkYWxlbnMgRGF0YWtv
bnN1bHQgQUIgRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp
bDEaMBgGA1UEAxMRR2l1c2VwcGUgRCdBbmdlbG8xKDAmBgkqhkiG9w0BCQEWGWdpdXNlcHBl
LmRhbmdlbG9Aa2RhYi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRpPKl
9ZyLpQ/UM/zcNoWrwg55cHjp+qvQT3iivgGuxP7Tg6ceAo72kwlIyZ6Prys0/wn6FN7mFZi/
r4jIV+pCgBjRjRcEHhplGA7MOmHCIznYqaBrVJmaZr3XaRukQbQNXTwhaQGOPG3Ss/LGnJyx
YT6i0WAWHSw8tWhoASCbWHt8x0lBR2ZqWbTI3sAyzhCKgijlscAQV79L8/KjQ1gSc1tMtk0o
+H2kts+h3UaUHMTxd3yy6T2azN7p7wgwUXTHD8PkvAD00OYlUYjerGWrj+bGOeX8fC5FXzH+
57PN/I1i/BVZsnMPFsYD3ItprlXF4SvUZypL9UGVvrTM4SUtAgMBAAGjggHhMIIB3TAfBgNV
HSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUyvEat8Z6o8LLMytHSJlF
ACE1k8swDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUH
AwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEW
HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6
Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5k
U2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRw
Oi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j
b20wJAYDVR0RBB0wG4EZZ2l1c2VwcGUuZGFuZ2Vsb0BrZGFiLmNvbTANBgkqhkiG9w0BAQsF
AAOCAQEAHrkxe9D8UqNNq5kfMk7c3SBS6KeZrVJcO/W095VYnsAGnm9C+F75oxYbr54oFlfs
N1Jfn7lyN0CxRyaptiWpL67dgkNYk0LHT2/3vdAnEwPiwk/nW0HGAZ1EZ+VplkFCMtyWjmo6
RBaaWCUX2z0XYnfCzAm0UwKilkj8x/3EagpYlIBwEywPcEFJioPhdnGqs52pCY+edDFIx95a
Bremy6bXYDeDZGwBO+Ya0dyeSIovZ3mO/M9yogoAXWbM7tVBbTy4ztBNnJOjncQD4WH8Dho7
K7x8l2pgzPxH93Gwt+hmJeFCi86Ajh4CFl+ODPCo8KypKSaNzU2SIq5djsYkGDGCBEEwggQ9
AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw
DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4
Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEEVXnY6AI8AxmaqS9oOB86kwDQYJYIZIAWUDBAIBBQCgggJhMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDIxOTExMjUzOVowLwYJKoZIhvcNAQkE
MSIEIKKOY7rbYjDDgHHpR7XO5kamdesBF4lpkTi7nqMgX2SHMGwGCSqGSIb3DQEJDzFfMF0w
CwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgcEGCSsGAQQBgjcQBDGB
szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENP
TU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB
AhBFV52OgCPAMZmqkvaDgfOpMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBFV52OgCPAMZmqkvaDgfOp
MA0GCSqGSIb3DQEBAQUABIIBAG/tpRUwPQPpDBD0/doD4CmYGq47ShqeAwOWWBPDFB5J9pfp
cfWgg8Jb+ihYNa0Ie1Ep1Rqok3yJq5dn55znWS9CRRoua9se3Hl95DSUgR/QRSAOGhId5MBM
TLY+JBR7nWac/Pj5qNPqQfHdyykb3oCTj9gnKQArqZLfvoLVtjkvDZxszqXaTokP2qYupSKb
yTtMrGla5Gm8v+MG9vnN6LKURj/oMuNad6YzZh5WUV6o+vXXX1pNyMO3SUhb9OnubLcXjU62
tapnwLqLAGNTiygyw0qA+EWFz/v/jT8FdpuVu/Jm5F9eSzQnqjKGvVUXfkP/NNia4DIoFDD2
mMb/hRIAAAAAAAA=
--------------ms000700020803040602090300--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Mon, 19 Feb 2018 11:28:37 -0800
Raw View
--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<R,R> 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
<div dir=3D"ltr">On Mon, Feb 19, 2018 at 3:25 AM, Giuseppe D'Angelo <sp=
an dir=3D"ltr"><<a href=3D"mailto:giuseppe.dangelo@kdab.com" target=3D"_=
blank">giuseppe.dangelo@kdab.com</a>></span> wrote:<br><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-=
">On 19/02/18 07:04, Arthur O'Dwyer wrote:<br>
><br>
> Structured-binding to a complex number's parts seems like a slam-d=
unk.<br>
> Unfortunately, not everything that can be structured-binded is<br>
> necessarily "tuple-like". To me it seems wrong to treat &quo=
t;complex number"<br>
> as a special case of "tuple" throughout your entire codebase=
.. If you're<br>
> asking for the tuple_size of a complex number, you are almost certainl=
y<br>
> doing something wrong, IMO.<br>
<br>
</span>Unfortunately (?), that's the customization point we have to mak=
e UDTs<br>
work with structured bindings. So why not using it?=C2=A0<span class=3D"gma=
il-"><br></span></blockquote><div><br></div><div>I think we agree on the pr=
emises, we just disagree on the appropriate solution.</div><div>(A) To be a=
chieved: Unpack a complex number into a pair<R,R> of its real and ima=
ginary parts.</div><div>(B) If we use structured binding to unpack it, then=
someone must add specializations of tuple_size etc. in namespace std.</div=
><div>(C) If we add specializations of tuple_size etc. in namespace std, th=
en our program will be non-conforming.</div><div>The OP proposed this solut=
ion:</div><div>(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.</di=
v><div>I proposed two alternative solutions:</div><div>(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.</div><div>(3, for C=
++11) We unpack it without using structured binding.</div><div><br></div><d=
iv>I think (3) is far and away the best solution.</div><div><br></div><div>=
<br></div><div>> (Yes, I agree on the=C2=A0general principle, asking for=
the tuple_size of an arbitrary "Employee"=C2=A0class seems weird=
..)<br></div><div><br></div><div>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</i> 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 <i>not</i> to be provided" category.</div><div><br></div><div>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 <i>does</i> quack like a tuple, you'=
d darn well better <i>not</i> make it <i>look</i> like a tuple.</div><div><=
br></div><div>Arthur</div><div><br></div><div>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:</div><div>=C2=A0 =C2=A0 auto& [x, y] =3D z;</div><div>=C2=A0 =
=C2=A0 x =3D 42;</div><div>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.</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0JEQfY_9mwRyZM%2B8UP5RqB2wkfqYq=
kO_Egfx1FLisG%3D%3Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JEQf=
Y_9mwRyZM%2B8UP5RqB2wkfqYqkO_Egfx1FLisG%3D%3Dw%40mail.gmail.com</a>.<br />
--001a114011e267e674056595b36b--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Tue, 20 Feb 2018 00:41:00 -0800 (PST)
Raw View
------=_Part_15050_1173602704.1519116060156
Content-Type: multipart/alternative;
boundary="----=_Part_15051_805766762.1519116060157"
------=_Part_15051_805766762.1519116060157
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno marted=C3=AC 20 febbraio 2018 03:51:25 UTC+1, bogdan ha scritto:
>
>
> On Tuesday, February 20, 2018 at 3:14:49 AM UTC+2, bogdan wrote:
>>
>>
>>
>> Sorry for stating the obvious, but I haven't seen this mentioned above.=
=20
>> Maybe it helps the discussion.
>>
>> This is already guaranteed to work=20
>> <http://eel.is/c++draft/complex.numbers#4>:
>>
>> void f(std::complex<double> c)
>> {
>> auto [re, im] =3D reinterpret_cast<double(&)[2]>(c);
>> // ...
>> }
>>
>> auto& [re, im] works just as well. It actually generates better code=20
>> inside f; anyway, both versions are optimized quite nicely once inlining=
=20
>> kicks in, at least in this toy example: https://godbolt.org/g/8DCLUn
>>
>> Maybe having a nicer wrapper around that cast, allowing things like auto=
&=20
>> [re, im] =3D to_array(c);, would be enough? Rvalue arguments would need=
=20
>> special care - perhaps return an std::array by value in that case?
>>
>>
> Unfortunately, it also features the usual built-in array snags: auto& arr=
=20
> =3D reinterpret_cast<double(&)[2]>(c); is great, but in auto arr =3D=20
> reinterpret_cast<double(&)[2]>(c); arr is, of course, a double*.
>
>
That's exactly what I was going to post, you beat me to it. Having a=20
to_array() function (either member or non-member) would be very useful and=
=20
I would be happy with that, provided it can return std::array<T,2> and not=
=20
T[2]. Returning an array is a problem because of the decay issues you=20
mentioned, but, unfortunately, using std::array has two problems one small=
=20
and one big: 1) it creates a dependency between <complex> and <array> that=
=20
someone might frown upon, 2) I can't find normative text that guarantees=20
that reinterpret_cast<std::array<T,2>&>(c) has defined behaviour. A strict=
=20
reading of [array] leads me to believe that an std::array is allowed to=20
have padding or a different alignment from the underlying C array it=20
contains. In other words, if a is an std::array, a.data() is not required=
=20
to be addressof(a). Does anyone know what implementations do in this regard=
?
--=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/a7339131-93b4-4bc3-82a7-f817f851b0b4%40isocpp.or=
g.
------=_Part_15051_805766762.1519116060157
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno marted=C3=AC 20 febbraio 2018 03:51:25 UTC+1, bo=
gdan ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><br>On Tuesday, February 20, 2018 at 3:14:49 AM UTC+2, bogdan wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br>Sorry for=
stating the obvious, but I haven't seen this mentioned above. Maybe it=
helps the discussion.<br><br>This is already <a href=3D"http://eel.is/c++d=
raft/complex.numbers#4" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"t=
his.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2=
Bdraft%2Fcomplex.numbers%234\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFmLX1r=
FrvT_YIGNVFaW5SYPSKvVw';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fcomplex.numb=
ers%234\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFmLX1rFrvT_YIGNVFaW5SYPSKvV=
w';return true;">guaranteed to work</a>:<br><br><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px"><code><div><span style=3D"color:#008">void</span><span sty=
le=3D"color:#000"> f</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">std</span><span style=3D"color:#660">::</span><span style=
=3D"color:#000">complex</span><span style=3D"color:#080"><double></sp=
an><span style=3D"color:#000"> c</span><span style=3D"color:#660">)</span><=
span style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><sp=
an style=3D"color:#000"><br>=C2=A0 =C2=A0</span><span style=3D"color:#008">=
auto</span><span style=3D"color:#000"> </span><span style=3D"color:#660">[<=
/span><span style=3D"color:#000">re</span><span style=3D"color:#660">,</spa=
n><span style=3D"color:#000"> im</span><span style=3D"color:#660">]</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">reinterpret_cast<=
/span><span style=3D"color:#660"><</span><span style=3D"color:#008">doub=
le</span><span style=3D"color:#660">(&)[</span><span style=3D"color:#06=
6">2</span><span style=3D"color:#660">]><wbr>(</span><span style=3D"colo=
r:#000">c</span><span style=3D"color:#660">);</span><span style=3D"color:#0=
00"><br>=C2=A0 =C2=A0</span><span style=3D"color:#800">// ...</span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span sty=
le=3D"color:#000"><br></span></div></code></div><br><span>auto& [re, im=
]</span> works just as well. It actually generates better code inside <span=
>f</span>; anyway, both versions are optimized quite nicely once inlining k=
icks in, at least in this toy example: <a href=3D"https://godbolt.org/g/8DC=
LUn" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'htt=
ps://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2F8DCLUn\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHoUzYTFDrMIt8sIHQfkF4Kn95lPA';return t=
rue;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%=
2F%2Fgodbolt.org%2Fg%2F8DCLUn\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHoUzY=
TFDrMIt8sIHQfkF4Kn95lPA';return true;">https://godbolt.org/g/8DCLUn</a>=
<br><br>Maybe having a nicer wrapper around that cast, allowing things like=
<span>auto& [re, im] =3D to_array(c);</span>, would be enough? Rvalue =
arguments would need special care - perhaps return an <span>std::array</spa=
n> by value in that case?<br><br></div></div></blockquote><div><br>Unfortun=
ately, it also features the usual built-in array snags: <span>auto& arr=
=3D reinterpret_cast<double(&)[2]><wbr>(c);</span> is great, but=
in <span>auto arr =3D reinterpret_cast<double(&)[2]><wbr>(c);</s=
pan> <span>arr</span> is, of course, a <span>double*</span>.<br><br></div><=
/div></blockquote><div><br>That's exactly what I was going to post, you=
beat me to it. Having a to_array() function (either member or non-member) =
would be very useful and I would be happy with that, provided it can return=
std::array<T,2> and not T[2]. Returning an array is a problem becaus=
e of the decay issues you mentioned, but, unfortunately, using std::array h=
as two problems one small and one big: 1) it creates a dependency between &=
lt;complex> and <array> that someone might frown upon, 2) I can=
9;t find normative text that guarantees that reinterpret_cast<std::array=
<T,2>&>(c) has defined behaviour. A strict reading of [array] =
leads me to believe that an std::array is allowed to have padding or a diff=
erent alignment from the underlying C array it contains. In other words, if=
a is an std::array, a.data() is not required to be addressof(a). Does anyo=
ne know what implementations do in this regard?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a7339131-93b4-4bc3-82a7-f817f851b0b4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a7339131-93b4-4bc3-82a7-f817f851b0b4=
%40isocpp.org</a>.<br />
------=_Part_15051_805766762.1519116060157--
------=_Part_15050_1173602704.1519116060156--
.
Author: bogdan <bogdan.iordanescu@gmail.com>
Date: Tue, 20 Feb 2018 02:55:46 -0800 (PST)
Raw View
------=_Part_15513_349757177.1519124146509
Content-Type: multipart/alternative;
boundary="----=_Part_15514_72652112.1519124146509"
------=_Part_15514_72652112.1519124146509
Content-Type: text/plain; charset="UTF-8"
On Tuesday, February 20, 2018 at 10:41:00 AM UTC+2, Alberto Barbati wrote:
>
>
> That's exactly what I was going to post, you beat me to it. Having a
> to_array() function (either member or non-member) would be very useful and
> I would be happy with that, provided it can return std::array<T,2> and not
> T[2]. Returning an array is a problem because of the decay issues you
> mentioned, but, unfortunately, using std::array has two problems one small
> and one big: 1) it creates a dependency between <complex> and <array> that
> someone might frown upon, 2) I can't find normative text that guarantees
> that reinterpret_cast<std::array<T,2>&>(c) has defined behaviour. A strict
> reading of [array] leads me to believe that an std::array is allowed to
> have padding or a different alignment from the underlying C array it
> contains. In other words, if a is an std::array, a.data() is not required
> to be addressof(a). Does anyone know what implementations do in this regard?
>
Even if everything is fine in terms of padding and alignment (and it
probably is), we still can't use the result of
reinterpret_cast<std::array<T,2>&>(c) to access c's members - that would be
undefined behaviour because there's no std::array<T, 2> object there. We
can use the result of the cast to T(&)[2] only because of the specific
wording in [complex.numbers]/4.
We would need a similar exception for casts to std::array<T, 2>& to make it
legal. At first glance, I'd say this would be a pretty good solution, but I
don't know how that looks from an implementation point of view.
--
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/a52a42ea-d539-4480-8e5a-f5fc87a0895b%40isocpp.org.
------=_Part_15514_72652112.1519124146509
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, February 20, 2018 at 10:41:00 AM UTC+2, Al=
berto Barbati wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><div>That's exactly what I was going to post, you beat me =
to it. Having a to_array() function (either member or non-member) would be =
very useful and I would be happy with that, provided it can return std::arr=
ay<T,2> and not T[2]. Returning an array is a problem because of the =
decay issues you mentioned, but, unfortunately, using std::array has two pr=
oblems one small and one big: 1) it creates a dependency between <comple=
x> and <array> that someone might frown upon, 2) I can't find =
normative text that guarantees that reinterpret_cast<std::array<T,<wb=
r>2>&>(c) has defined behaviour. A strict reading of [array] lead=
s me to believe that an std::array is allowed to have padding or a differen=
t alignment from the underlying C array it contains. In other words, if a i=
s an std::array, a.data() is not required to be addressof(a). Does anyone k=
now what implementations do in this regard?<br></div></div></blockquote><di=
v><br><br>Even if everything is fine in terms of padding and alignment (and=
it probably is), we still can't use the result of <span style=3D"font-=
family: courier\ new, monospace;">reinterpret_cast<std::array<T,2>=
&>(c)</span> to access <span style=3D"font-family: courier\ new, mon=
ospace;">c</span>'s members - that would be undefined behaviour because=
there's no <span style=3D"font-family: courier\ new, monospace;">std::=
array<T, 2></span> object there. We can use the result of the cast to=
<span style=3D"font-family: courier\ new, monospace;">T(&)[2]</span> o=
nly because of the specific wording in [complex.numbers]/4. <br><br>We woul=
d need a similar exception for casts to <span style=3D"font-family: courier=
\ new, monospace;">std::array<T, 2>&</span> to make it legal. At =
first glance, I'd say this would be a pretty good solution, but I don&#=
39;t know how that looks from an implementation point of view.<br><br></div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a52a42ea-d539-4480-8e5a-f5fc87a0895b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a52a42ea-d539-4480-8e5a-f5fc87a0895b=
%40isocpp.org</a>.<br />
------=_Part_15514_72652112.1519124146509--
------=_Part_15513_349757177.1519124146509--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Tue, 20 Feb 2018 03:07:45 -0800 (PST)
Raw View
------=_Part_15305_1226738679.1519124865661
Content-Type: multipart/alternative;
boundary="----=_Part_15306_1766575351.1519124865661"
------=_Part_15306_1766575351.1519124865661
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno marted=C3=AC 20 febbraio 2018 11:55:46 UTC+1, bogdan ha scritto:
>
>
> On Tuesday, February 20, 2018 at 10:41:00 AM UTC+2, Alberto Barbati wrote=
:
>>
>>
>> That's exactly what I was going to post, you beat me to it. Having a=20
>> to_array() function (either member or non-member) would be very useful a=
nd=20
>> I would be happy with that, provided it can return std::array<T,2> and n=
ot=20
>> T[2]. Returning an array is a problem because of the decay issues you=20
>> mentioned, but, unfortunately, using std::array has two problems one sma=
ll=20
>> and one big: 1) it creates a dependency between <complex> and <array> th=
at=20
>> someone might frown upon, 2) I can't find normative text that guarantees=
=20
>> that reinterpret_cast<std::array<T,2>&>(c) has defined behaviour. A stri=
ct=20
>> reading of [array] leads me to believe that an std::array is allowed to=
=20
>> have padding or a different alignment from the underlying C array it=20
>> contains. In other words, if a is an std::array, a.data() is not require=
d=20
>> to be addressof(a). Does anyone know what implementations do in this reg=
ard?
>>
>
>
> Even if everything is fine in terms of padding and alignment (and it=20
> probably is), we still can't use the result of=20
> reinterpret_cast<std::array<T,2>&>(c) to access c's members - that would=
=20
> be undefined behaviour because there's no std::array<T, 2> object there.=
=20
> We can use the result of the cast to T(&)[2] only because of the specific=
=20
> wording in [complex.numbers]/4.=20
>
> We would need a similar exception for casts to std::array<T, 2>& to make=
=20
> it legal. At first glance, I'd say this would be a pretty good solution,=
=20
> but I don't know how that looks from an implementation point of view.
>
Assuming there are no implementation issues with padding/alignment, I=20
believe it would suffice to add a member function to std::complex<T> with=
=20
wording like this:
*std::array<T, 2>& to_array() noexcept;*
*Returns*: a reference to an std::array<T, 2> object a such that:
- a[0] =3D=3D real()
- a[1] =3D=3D imag()
- addressof(a) =3D=3D addressof(*this)
[Note: no copy is performed -- end note]
Whether the function is implemented using reinterpret_cast or some compiler=
=20
magic is an implementation detail that need not be mentioned.
PS: the provided wording is an example. We would need to carefully consider=
=20
&/&&/const/constexpr/etc. variants.
--=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/30420892-79f2-40e8-a64a-2e896828035d%40isocpp.or=
g.
------=_Part_15306_1766575351.1519124865661
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno marted=C3=AC 20 febbraio 2018 11:55:46 UTC+1, bo=
gdan ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><br>On Tuesday, February 20, 2018 at 10:41:00 AM UTC+2, Alberto Barbati =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>Tha=
t's exactly what I was going to post, you beat me to it. Having a to_ar=
ray() function (either member or non-member) would be very useful and I wou=
ld be happy with that, provided it can return std::array<T,2> and not=
T[2]. Returning an array is a problem because of the decay issues you ment=
ioned, but, unfortunately, using std::array has two problems one small and =
one big: 1) it creates a dependency between <complex> and <array&g=
t; that someone might frown upon, 2) I can't find normative text that g=
uarantees that reinterpret_cast<std::array<T,<wbr>2>&>(c) h=
as defined behaviour. A strict reading of [array] leads me to believe that =
an std::array is allowed to have padding or a different alignment from the =
underlying C array it contains. In other words, if a is an std::array, a.da=
ta() is not required to be addressof(a). Does anyone know what implementati=
ons do in this regard?<br></div></div></blockquote><div><br><br>Even if eve=
rything is fine in terms of padding and alignment (and it probably is), we =
still can't use the result of <span>reinterpret_cast<std::array<T=
,<wbr>2>&>(c)</span> to access <span>c</span>'s members - tha=
t would be undefined behaviour because there's no <span>std::array<T=
, 2></span> object there. We can use the result of the cast to <span>T(&=
amp;)[2]</span> only because of the specific wording in [complex.numbers]/4=
.. <br><br>We would need a similar exception for casts to <span>std::array&l=
t;T, 2>&</span> to make it legal. At first glance, I'd say this =
would be a pretty good solution, but I don't know how that looks from a=
n implementation point of view.<br></div></div></blockquote><div><br>Assumi=
ng there are no implementation issues with padding/alignment, I believe it =
would suffice to add a member function to std::complex<T> with wordin=
g like this:<br><br><b><span style=3D"font-family: courier\ new, monospace;=
">std::array<T, 2>& to_array() noexcept;</span><br></b><br><i>Ret=
urns</i>: a reference to an <span style=3D"font-family: courier\ new, monos=
pace;">std::array<T, 2></span> object <span style=3D"font-family: cou=
rier\ new, monospace;">a </span>such that:<br><ul><li><span style=3D"font-f=
amily: courier\ new, monospace;">a[0] =3D=3D real()</span></li><li><span st=
yle=3D"font-family: courier\ new, monospace;">a[1] =3D=3D imag()</span></li=
><li><span style=3D"font-family: courier\ new, monospace;">addressof(a) =3D=
=3D addressof(*this)</span></li></ul>[Note: no copy is performed -- end not=
e]<br><br>Whether the function is implemented using reinterpret_cast or som=
e compiler magic is an implementation detail that need not be mentioned.<br=
><br>PS: the provided wording is an example. We would need to carefully con=
sider &/&&/const/constexpr/etc. variants.<br><br><br></div></di=
v>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/30420892-79f2-40e8-a64a-2e896828035d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/30420892-79f2-40e8-a64a-2e896828035d=
%40isocpp.org</a>.<br />
------=_Part_15306_1766575351.1519124865661--
------=_Part_15305_1226738679.1519124865661--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 20 Feb 2018 13:03:01 -0600
Raw View
--f403045dd47215b3270565a97835
Content-Type: text/plain; charset="UTF-8"
On Tue, Feb 20, 2018 at 5:07 AM, Alberto Barbati <albertobarbati@gmail.com>
wrote:
> Assuming there are no implementation issues with padding/alignment, I
> believe it would suffice to add a member function to std::complex<T> with
> wording like this:
>
>
> *std::array<T, 2>& to_array() noexcept;*
> *Returns*: a reference to an std::array<T, 2> object a such that:
>
> - a[0] == real()
> - a[1] == imag()
> - addressof(a) == addressof(*this)
>
> If what you want to do is have the standard specify the implementation,
then propose that instead of these convoluted functions.
Of course, if you do that,
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BO55AkfNek8b3MGtaUOH5UBdacYa9RzAECzzn6Z8ry9Bw%40mail.gmail.com.
--f403045dd47215b3270565a97835
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Feb 20, 2018 at 5:07 AM, Alberto Barbati <span dir=
=3D"ltr"><<a href=3D"mailto:albertobarbati@gmail.com" target=3D"_blank">=
albertobarbati@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>Assuming there are no implementation issues with padding/alignment, =
I believe it would suffice to add a member function to std::complex<T>=
; with wording like this:<br><br><b><span>std::array<T, 2>& to_ar=
ray() noexcept;</span><br></b><br><i>Returns</i>: a reference to an <span>s=
td::array<T, 2></span> object <span>a </span>such that:<br><ul><li><s=
pan>a[0] =3D=3D real()</span></li><li><span>a[1] =3D=3D imag()</span></li><=
li><span>addressof(a) =3D=3D addressof(*this)</span></li></ul></div></div><=
/blockquote><div>If what you want to do is have the standard specify the im=
plementation, then propose that instead of these convoluted functions.</div=
><div><br></div><div>Of course, if you do that,=C2=A0</div></div>-- <br><di=
v class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"=
ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <=
;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@e=
viloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BO55AkfNek8b3MGtaUOH5UBdacYa9=
RzAECzzn6Z8ry9Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BO55Akf=
Nek8b3MGtaUOH5UBdacYa9RzAECzzn6Z8ry9Bw%40mail.gmail.com</a>.<br />
--f403045dd47215b3270565a97835--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 19 Feb 2018 15:56:21 -0500
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Doesn't structured bindings already work with plain structs, wi=
thout any specialization?</div><div style=3D"width: 100%; font-size: initia=
l; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31=
, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br=
></div><div style=3D"width: 100%; font-size: initial; font-family: Calibri,=
'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: =
initial; background-color: rgb(255, 255, 255);">std::complex isn't much mor=
e than a struct (well, except for possible compatibility with C)</div><div =
style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro'=
, sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; bac=
kground-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">But, importantly, it has no invariants, so exposing it via SB i=
s similar to exposing a struct.</div><div style=3D"width: 100%; font-size: =
initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: =
rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255)=
;"><br></div><div style=3D"width: 100%; font-size: initial; font-family: Ca=
libri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-a=
lign: initial; background-color: rgb(255, 255, 255);">Your P.S. example sho=
uld be no different than how that works with pairs and structs.</div> =
=
<div style=3D"width: 10=
0%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans=
-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb=
(255, 255, 255);"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-family: Cali=
bri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-ali=
gn: initial; background-color: rgb(255, 255, 255);">Sent from my&=
nbsp;BlackBerry portable Babbage Device</div> =
=
=
<table width=3D"100%" style=3D"background-color:white;border-s=
pacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; tex=
t-align: initial; background-color: rgb(255, 255, 255);"> =
<div style=3D"border-style: solid none none; border-top-color: rgb=
(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: =
Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b=
>Arthur O'Dwyer</div><div><b>Sent: </b>Monday, February 19, 2018 2:28 PM</d=
iv><div><b>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply T=
o: </b>std-proposals@isocpp.org</div><div><b>Subject: </b>Re: [std-proposal=
s] Two proposed additions to std::complex</div></div></td></tr></tbody></ta=
ble><div style=3D"border-style: solid none none; border-top-color: rgb(186,=
188, 209); border-top-width: 1pt; font-size: initial; text-align: initial;=
background-color: rgb(255, 255, 255);"></div><br><div id=3D"_originalConte=
nt" style=3D""><div dir=3D"ltr">On Mon, Feb 19, 2018 at 3:25 AM, Giuseppe D=
'Angelo <span dir=3D"ltr"><<a href=3D"mailto:giuseppe.dangelo@kdab.com" =
target=3D"_blank">giuseppe.dangelo@kdab.com</a>></span> wrote:<br><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span clas=
s=3D"gmail-">On 19/02/18 07:04, Arthur O'Dwyer wrote:<br>
><br>
> Structured-binding to a complex number's parts seems like a slam-dunk.=
<br>
> Unfortunately, not everything that can be structured-binded is<br>
> necessarily "tuple-like". To me it seems wrong to treat "complex numbe=
r"<br>
> as a special case of "tuple" throughout your entire codebase. If you'r=
e<br>
> asking for the tuple_size of a complex number, you are almost certainl=
y<br>
> doing something wrong, IMO.<br>
<br>
</span>Unfortunately (?), that's the customization point we have to make UD=
Ts<br>
work with structured bindings. So why not using it? <span class=3D"gma=
il-"><br></span></blockquote><div><br></div><div>I think we agree on the pr=
emises, we just disagree on the appropriate solution.</div><div>(A) To be a=
chieved: Unpack a complex number into a pair<R,R> of its real and ima=
ginary parts.</div><div>(B) If we use structured binding to unpack it, then=
someone must add specializations of tuple_size etc. in namespace std.</div=
><div>(C) If we add specializations of tuple_size etc. in namespace std, th=
en our program will be non-conforming.</div><div>The OP proposed this solut=
ion:</div><div>(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.</di=
v><div>I proposed two alternative solutions:</div><div>(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.</div><div>(3, for C=
++11) We unpack it without using structured binding.</div><div><br></div><d=
iv>I think (3) is far and away the best solution.</div><div><br></div><div>=
<br></div><div>> (Yes, I agree on the general principle, asking for=
the tuple_size of an arbitrary "Employee" class seems weird.)<br></di=
v><div><br></div><div>Also agreed. Personally I think that "Complex Number"=
is much closer to "Employee" than to "Tuple". Or anyway, there are a certa=
in set of operations I would naturally expect to be provided for "Complex N=
umbers", such as operator+ and operator*; and there are a certain set of op=
erations I would expect <i>not</i> to be provided, such as .salary() and .s=
ize(); and then there's this operation tuple_size, which I personally also =
put in the "expect <i>not</i> to be provided" category.</div><div><br></div=
><div>We have to be particularly careful about adding new general-purpose o=
perations 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 fund=
amentally encourage library programming based on syntactic constraints =E2=
=80=94 "looks like a tuple, so let's just assume it walks and quacks like a=
tuple." So unless it really <i>does</i> quack like a tuple, you'd darn wel=
l better <i>not</i> make it <i>look</i> like a tuple.</div><div><br></div><=
div>Arthur</div><div><br></div><div>P.S. =E2=80=94 If this idea does move f=
orward, you should consider whether you want this to work, and if so, how:<=
/div><div> auto& [x, y] =3D z;</div><div> x =
=3D 42;</div><div>I'm not saying it's hard to make it work; just that you o=
ught to discuss the pros and cons in whatever proposal might come out of th=
is.</div></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0JEQfY_9mwRyZM%2B8UP5RqB2wkfqYq=
kO_Egfx1FLisG%3D%3Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0=
JEQfY_9mwRyZM%2B8UP5RqB2wkfqYqkO_Egfx1FLisG%3D%3Dw%40mail.gmail.com</a>.<br=
>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20180219205621.5111891.69117.45816%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20180219205621.5111891.69117.45816%40gm=
ail.com</a>.<br />
.
Author: bogdan.iordanescu@gmail.com
Date: Mon, 19 Feb 2018 17:14:49 -0800 (PST)
Raw View
------=_Part_3979_248281097.1519089289480
Content-Type: multipart/alternative;
boundary="----=_Part_3980_1129994147.1519089289480"
------=_Part_3980_1129994147.1519089289480
Content-Type: text/plain; charset="UTF-8"
On Monday, February 19, 2018 at 10:56:30 PM UTC+2, Tony V E wrote:
>
> Doesn't structured bindings already work with plain structs, without any
> specialization?
>
> std::complex isn't much more than a struct (well, except for possible
> compatibility with C)
>
> But, importantly, it has no invariants, so exposing it via SB is similar
> to exposing a struct.
>
> Your P.S. example should be no different than how that works with pairs
> and structs.
>
> Sent from my BlackBerry portable Babbage Device
>
>
>
Sorry for stating the obvious, but I haven't seen this mentioned above.
Maybe it helps the discussion.
This is already guaranteed to work
<http://eel.is/c++draft/complex.numbers#4>:
void f(std::complex<double> c)
{
auto [re, im] = reinterpret_cast<double(&)[2]>(c);
// ...
}
auto& [re, im] works just as well. It actually generates better code inside
f; anyway, both versions are optimized quite nicely once inlining kicks in,
at least in this toy example: https://godbolt.org/g/8DCLUn
Maybe having a nicer wrapper around that cast, allowing things like auto&
[re, im] = to_array(c);, would be enough? Rvalue arguments would need
special care - perhaps return an std::array by value in that case?
--
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/5cb24c4f-9952-4aac-a4d4-1ed030148b3a%40isocpp.org.
------=_Part_3980_1129994147.1519089289480
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Monday, February 19, 2018 at 10:56:30 PM UTC+2, Ton=
y V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"back=
ground-color:rgb(255,255,255);line-height:initial" lang=3D"en-US"> =
=
<div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate=
Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;bac=
kground-color:rgb(255,255,255)">Doesn't structured bindings already wor=
k with plain structs, without any specialization?</div><div style=3D"width:=
100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,s=
ans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,=
255,255)"><br></div><div style=3D"width:100%;font-size:initial;font-family:=
Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text=
-align:initial;background-color:rgb(255,255,255)">std::complex isn't mu=
ch more than a struct (well, except for possible compatibility with C)</div=
><div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate =
Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;back=
ground-color:rgb(255,255,255)"><br></div><div style=3D"width:100%;font-size=
:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;colo=
r:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">But,=
importantly, it has no invariants, so exposing it via SB is similar to exp=
osing a struct.</div><div style=3D"width:100%;font-size:initial;font-family=
:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);tex=
t-align:initial;background-color:rgb(255,255,255)"><br></div><div style=3D"=
width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-s=
erif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rg=
b(255,255,255)">Your P.S. example should be no different than how that work=
s with pairs and structs.</div> =
=
<div style=3D"width:100%;font-size:initial;font-family:Calibr=
i,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align=
:initial;background-color:rgb(255,255,255)"><br style=3D"display:initial"><=
/div> =
=
<div style=3D"font-size:i=
nitial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:=
rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">Sent=
=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0<wbr>portable=C2=A0Babbage=C2=A0Dev=
ice</div> =
=
<table style=3D"background-color:white=
;border-spacing:0px" width=3D"100%"> <tbody><tr><td colspan=3D"2" style=3D"=
font-size:initial;text-align:initial;background-color:rgb(255,255,255)"><br=
></td></tr></tbody></table><br></div></blockquote><div><br><br>Sorry for st=
ating the obvious, but I haven't seen this mentioned above. Maybe it he=
lps the discussion.<br><br>This is already <a href=3D"http://eel.is/c++draf=
t/complex.numbers#4">guaranteed to work</a>:<br><br><div style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprin=
t"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">complex</span><span style=3D"color: #080;" class=3D"styled-by-prettif=
y"><double></span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> c</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">re</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> im</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">]</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">reinterpret_cast</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">double</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(&)[</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">]>(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">c</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// ...</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span></div></code></div><br><span style=3D"font-family: courier\=
new, monospace;">auto& [re, im]</span> works just as well. It actually=
generates better code inside <span style=3D"font-family: courier\ new, mon=
ospace;">f</span>; anyway, both versions are optimized quite nicely once in=
lining kicks in, at least in this toy example: <a href=3D"https://godbolt.o=
rg/g/8DCLUn">https://godbolt.org/g/8DCLUn</a><br><br>Maybe having a nicer w=
rapper around that cast, allowing things like <span style=3D"font-family: c=
ourier\ new, monospace;">auto& [re, im] =3D to_array(c);</span>, would =
be enough? Rvalue arguments would need special care - perhaps return an <sp=
an style=3D"font-family: courier\ new, monospace;">std::array</span> by val=
ue in that case?<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5cb24c4f-9952-4aac-a4d4-1ed030148b3a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5cb24c4f-9952-4aac-a4d4-1ed030148b3a=
%40isocpp.org</a>.<br />
------=_Part_3980_1129994147.1519089289480--
------=_Part_3979_248281097.1519089289480--
.
Author: bogdan <bogdan.iordanescu@gmail.com>
Date: Mon, 19 Feb 2018 18:51:25 -0800 (PST)
Raw View
------=_Part_14598_1643114550.1519095085467
Content-Type: multipart/alternative;
boundary="----=_Part_14599_1972616791.1519095085468"
------=_Part_14599_1972616791.1519095085468
Content-Type: text/plain; charset="UTF-8"
On Tuesday, February 20, 2018 at 3:14:49 AM UTC+2, bogdan wrote:
>
>
> On Monday, February 19, 2018 at 10:56:30 PM UTC+2, Tony V E wrote:
>>
>> Doesn't structured bindings already work with plain structs, without any
>> specialization?
>>
>> std::complex isn't much more than a struct (well, except for possible
>> compatibility with C)
>>
>> But, importantly, it has no invariants, so exposing it via SB is similar
>> to exposing a struct.
>>
>> Your P.S. example should be no different than how that works with pairs
>> and structs.
>>
>> Sent from my BlackBerry portable Babbage Device
>>
>>
>>
>
> Sorry for stating the obvious, but I haven't seen this mentioned above.
> Maybe it helps the discussion.
>
> This is already guaranteed to work
> <http://eel.is/c++draft/complex.numbers#4>:
>
> void f(std::complex<double> c)
> {
> auto [re, im] = reinterpret_cast<double(&)[2]>(c);
> // ...
> }
>
> auto& [re, im] works just as well. It actually generates better code
> inside f; anyway, both versions are optimized quite nicely once inlining
> kicks in, at least in this toy example: https://godbolt.org/g/8DCLUn
>
> Maybe having a nicer wrapper around that cast, allowing things like auto&
> [re, im] = to_array(c);, would be enough? Rvalue arguments would need
> special care - perhaps return an std::array by value in that case?
>
>
Unfortunately, it also features the usual built-in array snags: auto& arr =
reinterpret_cast<double(&)[2]>(c); is great, but in auto arr =
reinterpret_cast<double(&)[2]>(c); arr is, of course, a double*.
--
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/da0c85ac-e07c-439e-9e0f-b0c2a497ca92%40isocpp.org.
------=_Part_14599_1972616791.1519095085468
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, February 20, 2018 at 3:14:49 AM UTC+2, bog=
dan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br=
>On Monday, February 19, 2018 at 10:56:30 PM UTC+2, Tony V E wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div style=3D"background-color:rgb(255,255,=
255);line-height:initial" lang=3D"en-US"> =
<div style=3D"width:100=
%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans=
-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255=
,255)">Doesn't structured bindings already work with plain structs, wit=
hout any specialization?</div><div style=3D"width:100%;font-size:initial;fo=
nt-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73=
,125);text-align:initial;background-color:rgb(255,255,255)"><br></div><div =
style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro=
9;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background=
-color:rgb(255,255,255)">std::complex isn't much more than a struct (we=
ll, except for possible compatibility with C)</div><div style=3D"width:100%=
;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-=
serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,=
255)"><br></div><div style=3D"width:100%;font-size:initial;font-family:Cali=
bri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-ali=
gn:initial;background-color:rgb(255,255,255)">But, importantly, it has no i=
nvariants, so exposing it via SB is similar to exposing a struct.</div><div=
style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro&#=
39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgroun=
d-color:rgb(255,255,255)"><br></div><div style=3D"width:100%;font-size:init=
ial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb=
(31,73,125);text-align:initial;background-color:rgb(255,255,255)">Your P.S.=
example should be no different than how that works with pairs and structs.=
</div> =
<div style=
=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sa=
ns-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-colo=
r:rgb(255,255,255)"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size:initial;font-family:Calib=
ri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-alig=
n:initial;background-color:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0Bl=
ackBerry=C2=A0<wbr>portable=C2=A0Babbage=C2=A0Device</div> =
=
=
<table style=3D"background-color:white;border-spacing:0px" width=
=3D"100%"> <tbody><tr><td colspan=3D"2" style=3D"font-size:initial;text-ali=
gn:initial;background-color:rgb(255,255,255)"><br></td></tr></tbody></table=
><br></div></blockquote><div><br><br>Sorry for stating the obvious, but I h=
aven't seen this mentioned above. Maybe it helps the discussion.<br><br=
>This is already <a href=3D"http://eel.is/c++draft/complex.numbers#4" targe=
t=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.go=
ogle.com/url?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fcomplex.numbers%234\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFmLX1rFrvT_YIGNVFaW5SYPSKvVw';r=
eturn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhtt=
p%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fcomplex.numbers%234\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNFmLX1rFrvT_YIGNVFaW5SYPSKvVw';return true;">guarante=
ed to work</a>:<br><br><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><=
span style=3D"color:#008">void</span><span style=3D"color:#000"> f</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">std</span><span=
style=3D"color:#660">::</span><span style=3D"color:#000">complex</span><sp=
an style=3D"color:#080"><double></span><span style=3D"color:#000"> c<=
/span><span style=3D"color:#660">)</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0</span><span style=3D"color:#008">auto</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">[</span><span style=3D"color:#000=
">re</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> i=
m</span><span style=3D"color:#660">]</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#008">reinterpret_cast</span><span style=3D"color:#660=
"><</span><span style=3D"color:#008">double</span><span style=3D"color:#=
660">(&)[</span><span style=3D"color:#066">2</span><span style=3D"color=
:#660">]><wbr>(</span><span style=3D"color:#000">c</span><span style=3D"=
color:#660">);</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0</span><sp=
an style=3D"color:#800">// ...</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#660">}</span><span style=3D"color:#000"><br></span></=
div></code></div><br><span>auto& [re, im]</span> works just as well. It=
actually generates better code inside <span>f</span>; anyway, both version=
s are optimized quite nicely once inlining kicks in, at least in this toy e=
xample: <a href=3D"https://godbolt.org/g/8DCLUn" target=3D"_blank" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dht=
tps%3A%2F%2Fgodbolt.org%2Fg%2F8DCLUn\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNHoUzYTFDrMIt8sIHQfkF4Kn95lPA';return true;" onclick=3D"this.href=3D&#=
39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2F8DCLUn\x=
26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHoUzYTFDrMIt8sIHQfkF4Kn95lPA';re=
turn true;">https://godbolt.org/g/8DCLUn</a><br><br>Maybe having a nicer wr=
apper around that cast, allowing things like <span>auto& [re, im] =3D t=
o_array(c);</span>, would be enough? Rvalue arguments would need special ca=
re - perhaps return an <span>std::array</span> by value in that case?<br><b=
r></div></div></blockquote><div><br>Unfortunately, it also features the usu=
al built-in array snags: <span style=3D"font-family: courier\ new, monospac=
e;">auto& arr =3D reinterpret_cast<double(&)[2]>(c);</span> i=
s great, but in <span style=3D"font-family: courier\ new, monospace;">auto =
arr =3D reinterpret_cast<double(&)[2]>(c);</span> <span style=3D"=
font-family: courier\ new, monospace;">arr</span> is, of course, a <span st=
yle=3D"font-family: courier\ new, monospace;">double*</span>.<br><br></div>=
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/da0c85ac-e07c-439e-9e0f-b0c2a497ca92%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/da0c85ac-e07c-439e-9e0f-b0c2a497ca92=
%40isocpp.org</a>.<br />
------=_Part_14599_1972616791.1519095085468--
------=_Part_14598_1643114550.1519095085467--
.