Topic: Comments on P0081R0
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Sat, 28 Jan 2017 13:53:42 +0100
Raw View
Hi Paul, all,
I don't know the status of P0081, but in case it's still under
consideration, I have some API review comments.
I like the idea of returning by value, but using std::pair is
spectacularly bad API (I've written about why extensively here:
https://www.kdab.com/tuple-pair-cpp-apis/).
Please change the definition to
constexpr auto sincos(FloatingPoint x) noexcept {
struct result { FloatingPoint sin, cos; }; // exposition only
return result{std::sin(x), std::cos(x)};
}
where FloatingPoint \in \{float, double, long double, <any
implementation-defined FP type>\}.
std::tie does not need to work on the return value, we have Structured
Bindings now, so you can say
auto r = sincos(1.047);
// use r.sin, r.cos
or
auto [sin, cos] = sincos(1.047);
Thanks,
Marc
--
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/950a37bc55fbd69afd118bbb85ed8bb8%40kdab.com.
.
Author: Paul Dreik <paul.dreik@dreik.se>
Date: Sat, 28 Jan 2017 15:38:06 +0100
Raw View
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--sVV6RBFULXou5GdFxs42StsCTt7eFCxt3
Content-Type: multipart/mixed; boundary="7I2Xs4buraoN4NHU8JmPQIHAXpCxO8kek"
From: Paul Dreik <paul.dreik@dreik.se>
To: Marc Mutz <marc.mutz@kdab.com>,
ISO C++ Standard - Future Proposals <std-proposals@isocpp.org>
Cc: Lawrence@Crowl.org, jfb@google.com
Message-ID: <d6c8969d-7482-7fff-6776-cd889c69ffb1@dreik.se>
Subject: Re: Comments on P0081R0
References: <950a37bc55fbd69afd118bbb85ed8bb8@kdab.com>
In-Reply-To: <950a37bc55fbd69afd118bbb85ed8bb8@kdab.com>
--7I2Xs4buraoN4NHU8JmPQIHAXpCxO8kek
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi, thanks for the input!
That is an excellent suggestion. I wrote the proposal during cppcon 2015
and was not familiar with structure bindings at that point.
The only feedback I got was from JF Bastien and Lawrence Crowl, cc:d
from the committee internal email list. I did not hear anything more, so
I assumed it was not taken into consideration.
I tried out your proposal on compiler explorer, and it does not like the
constexpr since sin and cos are not constexpr.
Removing that, it seems like the abstractions go away at -O1 for gcc and
-O2 for clang. gcc calls its builtin sincos. Visual studio gives a long
output even at /Ox.
Here is a godbolted example:
https://godbolt.org/g/T6HtzY
Paul Dreik
Den 2017-01-28 kl. 13:53, skrev Marc Mutz:
> Hi Paul, all,
>=20
> I don't know the status of P0081, but in case it's still under
> consideration, I have some API review comments.
>=20
> I like the idea of returning by value, but using std::pair is
> spectacularly bad API (I've written about why extensively here:
> https://www.kdab.com/tuple-pair-cpp-apis/).
>=20
> Please change the definition to
>=20
> constexpr auto sincos(FloatingPoint x) noexcept {
> struct result { FloatingPoint sin, cos; }; // exposition only
> return result{std::sin(x), std::cos(x)};
> }
>=20
> where FloatingPoint \in \{float, double, long double, <any
> implementation-defined FP type>\}.
>=20
> std::tie does not need to work on the return value, we have Structured
> Bindings now, so you can say
>=20
> auto r =3D sincos(1.047);
> // use r.sin, r.cos
>=20
> or
>=20
> auto [sin, cos] =3D sincos(1.047);
>=20
> Thanks,
> Marc
>=20
--=20
Paul Dreik
Dreik Ingenj=C3=B6rskonst AB
URL: https://www.dreik.se/
Phone: +46 (0)73 99 26 333
skype: paul.dreik
--=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/d6c8969d-7482-7fff-6776-cd889c69ffb1%40dreik.se.
--7I2Xs4buraoN4NHU8JmPQIHAXpCxO8kek--
--sVV6RBFULXou5GdFxs42StsCTt7eFCxt3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJYjKzVAAoJEOB/VB2oTjSK8bkH/2Vy9dSfH0d8PUahzNZaPp/g
dULLoc/m7yQkQ2z1TdqjwDSbyAzjdAcI/L164g52/tilmIB3FXwM/8tqrQQ/Ifpt
HweG8ymg19bw310BPCdjZY+QYte6hAogdRRcb2Sh/LLDghh2XAu0e0MA1EaTqm68
iC2Fx1LWPpWcQonD0xi71bPYvS+dBtmM8P40znqHf6krDVVxamhEM0TMfJLjYJaR
8pJKm1It9vijRJ+BGFg67TkMzXD189OtnnABeVhb/omzkLzXhn2q+nEtqiMr4ehF
tXGy22p63ZCrw8DxzeON3+OjNzas/Kee/Y4wM6cuVoE3GVPqY8FlQ/C1e8JYzXI=
=Ahkq
-----END PGP SIGNATURE-----
--sVV6RBFULXou5GdFxs42StsCTt7eFCxt3--
.
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Sat, 28 Jan 2017 19:29:28 +0100
Raw View
Hi Paul,
Glad you like it.
On 2017-01-28 15:38, Paul Dreik wrote:
> Hi, thanks for the input!
> That is an excellent suggestion. I wrote the proposal during cppcon=20
> 2015
> and was not familiar with structure bindings at that point.
>=20
> The only feedback I got was from JF Bastien and Lawrence Crowl, cc:d
> from the committee internal email list. I did not hear anything more,=20
> so
> I assumed it was not taken into consideration.
>=20
> I tried out your proposal on compiler explorer, and it does not like=20
> the
> constexpr since sin and cos are not constexpr.
> Removing that, it seems like the abstractions go away at -O1 for gcc=20
> and
> -O2 for clang. gcc calls its builtin sincos. Visual studio gives a long
> output even at /Ox.
>=20
> Here is a godbolted example:
> https://godbolt.org/g/T6HtzY
I wouldn't take current compilers into account when judging the=20
interface. The idea here is to return an unnamed/unnam(e?)able struct=20
with proper member names instead of an over-engineered (for this=20
purpose) std::pair with non-descript member names 'first' and 'second'.=20
It should be just as optimisable as std::pair (or better), but with=20
strictly more readable call sites.
How the compilers then map this to an actual implementation is up to=20
them. As long as they return a struct with sin and cos members, every=20
implementation is allowed, and should not restrict implementations at=20
all.
Thanks,
Marc
> Paul Dreik
>=20
> Den 2017-01-28 kl. 13:53, skrev Marc Mutz:
>> Hi Paul, all,
>>=20
>> I don't know the status of P0081, but in case it's still under
>> consideration, I have some API review comments.
>>=20
>> I like the idea of returning by value, but using std::pair is
>> spectacularly bad API (I've written about why extensively here:
>> https://www.kdab.com/tuple-pair-cpp-apis/).
>>=20
>> Please change the definition to
>>=20
>> constexpr auto sincos(FloatingPoint x) noexcept {
>> struct result { FloatingPoint sin, cos; }; // exposition only
>> return result{std::sin(x), std::cos(x)};
>> }
>>=20
>> where FloatingPoint \in \{float, double, long double, <any
>> implementation-defined FP type>\}.
>>=20
>> std::tie does not need to work on the return value, we have Structured
>> Bindings now, so you can say
>>=20
>> auto r =3D sincos(1.047);
>> // use r.sin, r.cos
>>=20
>> or
>>=20
>> auto [sin, cos] =3D sincos(1.047);
>>=20
>> Thanks,
>> Marc
>>=20
>=20
> --
> Paul Dreik
> Dreik Ingenj=C3=B6rskonst AB
> URL: https://www.dreik.se/
> Phone: +46 (0)73 99 26 333
> skype: paul.dreik
--=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/9d303512fa90454fbe39dafaac360cd0%40kdab.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 28 Jan 2017 18:25:40 -0800 (PST)
Raw View
------=_Part_1100_649103881.1485656740382
Content-Type: multipart/alternative;
boundary="----=_Part_1101_2103702877.1485656740383"
------=_Part_1101_2103702877.1485656740383
Content-Type: text/plain; charset=UTF-8
On Saturday, January 28, 2017 at 1:29:45 PM UTC-5, Marc Mutz wrote:
>
> Hi Paul,
>
> Glad you like it.
>
> On 2017-01-28 15:38, Paul Dreik wrote:
> > Hi, thanks for the input!
> > That is an excellent suggestion. I wrote the proposal during cppcon
> > 2015
> > and was not familiar with structure bindings at that point.
> >
> > The only feedback I got was from JF Bastien and Lawrence Crowl, cc:d
> > from the committee internal email list. I did not hear anything more,
> > so
> > I assumed it was not taken into consideration.
> >
> > I tried out your proposal on compiler explorer, and it does not like
> > the
> > constexpr since sin and cos are not constexpr.
> > Removing that, it seems like the abstractions go away at -O1 for gcc
> > and
> > -O2 for clang. gcc calls its builtin sincos. Visual studio gives a long
> > output even at /Ox.
> >
> > Here is a godbolted example:
> > https://godbolt.org/g/T6HtzY
>
> I wouldn't take current compilers into account when judging the
> interface. The idea here is to return an unnamed/unnam(e?)able struct
> with proper member names instead of an over-engineered (for this
> purpose) std::pair with non-descript member names 'first' and 'second'.
> It should be just as optimisable as std::pair (or better), but with
> strictly more readable call sites.
>
While in general I might agree that a struct is usually more
self-descriptive at the point of use, for this *specific* case, I have to
disagree.
The very name of the function "sincos" tells you exactly what it returns
and in what order it returns them. As such, there is nothing at all
confusing about:
auto var = std::sincos(...);
doSomething(var.first);
It's abundantly clear to everyone exactly what is going on.
Like I said, I agree in general that structs are more clear than tuples for
multiple return values. But with this case, it's just too obvious what's
going on to bother with it.
How the compilers then map this to an actual implementation is up to
> them. As long as they return a struct with sin and cos members, every
> implementation is allowed, and should not restrict implementations at
> all.
>
Recall that <math.h> defines `sin` and `cos` as macros, not functions. That
makes it potentially problematic to use them as member names.
--
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/aeccba87-5401-4aca-af45-f092933d4cb5%40isocpp.org.
------=_Part_1101_2103702877.1485656740383
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, January 28, 2017 at 1:29:45 PM UTC-5,=
Marc Mutz wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi Paul,
<br>
<br>Glad you like it.
<br>
<br>On 2017-01-28 15:38, Paul Dreik wrote:
<br>> Hi, thanks for the input!
<br>> That is an excellent suggestion. I wrote the proposal during cppco=
n=20
<br>> 2015
<br>> and was not familiar with structure bindings at that point.
<br>>=20
<br>> The only feedback I got was from JF Bastien and Lawrence Crowl, cc=
:d
<br>> from the committee internal email list. I did not hear anything mo=
re,=20
<br>> so
<br>> I assumed it was not taken into consideration.
<br>>=20
<br>> I tried out your proposal on compiler explorer, and it does not li=
ke=20
<br>> the
<br>> constexpr since sin and cos are not constexpr.
<br>> Removing that, it seems like the abstractions go away at -O1 for g=
cc=20
<br>> and
<br>> -O2 for clang. gcc calls its builtin sincos. Visual studio gives a=
long
<br>> output even at /Ox.
<br>>=20
<br>> Here is a godbolted example:
<br>> <a href=3D"https://godbolt.org/g/T6HtzY" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dh=
ttps%3A%2F%2Fgodbolt.org%2Fg%2FT6HtzY\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNE0B6pCkH8HOvyJbADmTSEoapG2VQ';return true;" onclick=3D"this.href=3D&=
#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FT6HtzY\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE0B6pCkH8HOvyJbADmTSEoapG2VQ';r=
eturn true;">https://godbolt.org/g/T6HtzY</a>
<br>
<br>I wouldn't take current compilers into account when judging the=20
<br>interface. The idea here is to return an unnamed/unnam(e?)able struct=
=20
<br>with proper member names instead of an over-engineered (for this=20
<br>purpose) std::pair with non-descript member names 'first' and &=
#39;second'.=20
<br>It should be just as optimisable as std::pair (or better), but with=20
<br>strictly more readable call sites.<br></blockquote><div><br>While in ge=
neral I might agree that a struct is usually more self-descriptive at the p=
oint of use, for this <i>specific</i> case, I have to disagree.<br><br>The =
very name of the function "sincos" tells you exactly what it retu=
rns and in what order it returns them. As such, there is nothing at all con=
fusing about:<br><br><div style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; ove=
rflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">va=
r</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 st=
yle=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-prettify">sincos</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(...);</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>doSomething</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">var</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">first</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">);</span></div></code></div><br>It's abundantly clear to everyone ex=
actly what is going on.<br><br>Like I said, I agree in general that structs=
are more clear than tuples for multiple return values. But with this case,=
it's just too obvious what's going on to bother with it.<br><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
How the compilers then map this to an actual implementation is up to=20
<br>them. As long as they return a struct with sin and cos members, every=
=20
<br>implementation is allowed, and should not restrict implementations at=
=20
<br>all.<br></blockquote><br>Recall that <math.h> defines `sin` and `=
cos` as macros, not functions. That makes it potentially problematic to use=
them as member names.<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/aeccba87-5401-4aca-af45-f092933d4cb5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aeccba87-5401-4aca-af45-f092933d4cb5=
%40isocpp.org</a>.<br />
------=_Part_1101_2103702877.1485656740383--
------=_Part_1100_649103881.1485656740382--
.
Author: Chris Hallock <christopherhallock@gmail.com>
Date: Sat, 28 Jan 2017 20:34:38 -0800 (PST)
Raw View
------=_Part_4180_1163901920.1485664478427
Content-Type: multipart/alternative;
boundary="----=_Part_4181_2099173775.1485664478427"
------=_Part_4181_2099173775.1485664478427
Content-Type: text/plain; charset=UTF-8
On Saturday, January 28, 2017 at 9:25:40 PM UTC-5, Nicol Bolas wrote:
> Recall that <math.h> defines `sin` and `cos` as macros, not functions.
> That makes it potentially problematic to use them as member names.
>
Function-like macros, not object-like macros, which means the macro
expansion only triggers on sin( or cos(, which is not a problem in this
particular situation.
--
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/f896792a-bd29-4311-a8b0-29c619bfca3d%40isocpp.org.
------=_Part_4181_2099173775.1485664478427
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, January 28, 2017 at 9:25:40 PM UTC-5, Nicol B=
olas wrote:<br><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=
">Recall that <math.h> defines `sin` and `cos` as macros, not functio=
ns. That makes it potentially problematic to use them as member names.<br><=
/div></blockquote><div><br>Function-like macros, not object-like macros, wh=
ich means the macro expansion only triggers on <span style=3D"color: rgb(20=
4, 0, 0);"><span style=3D"font-family: courier new,monospace;">sin(</span><=
/span> or <span style=3D"color: rgb(204, 0, 0);"><span style=3D"font-family=
: courier new,monospace;">cos(</span></span>, which is not a problem in thi=
s particular situation.<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/f896792a-bd29-4311-a8b0-29c619bfca3d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f896792a-bd29-4311-a8b0-29c619bfca3d=
%40isocpp.org</a>.<br />
------=_Part_4181_2099173775.1485664478427--
------=_Part_4180_1163901920.1485664478427--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 29 Jan 2017 03:04:55 -0800
Raw View
--001a1147c6c84fe96c054739ab34
Content-Type: text/plain; charset=UTF-8
On 28 Jan 2017 8:34 pm, "Chris Hallock" <christopherhallock@gmail.com>
wrote:
On Saturday, January 28, 2017 at 9:25:40 PM UTC-5, Nicol Bolas wrote:
> Recall that <math.h> defines `sin` and `cos` as macros, not functions.
> That makes it potentially problematic to use them as member names.
>
Function-like macros, not object-like macros, which means the macro
expansion only triggers on sin( or cos(, which is not a problem in this
particular situation.
A conforming C++ implementation is required to provide only functions and
not macros here.
--
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/f896792a-bd29-4311-
a8b0-29c619bfca3d%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f896792a-bd29-4311-a8b0-29c619bfca3d%40isocpp.org?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/CAOfiQq%3D1igUrh48MjTW%2BmpZg2kX2MqUft0iaV8_7zigN1Wrmsw%40mail.gmail.com.
--001a1147c6c84fe96c054739ab34
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On 28 Jan 2017 8:34 pm, "Chris Hallock" <<a href=3D"mailto:c=
hristopherhallock@gmail.com">christopherhallock@gmail.com</a>> wrote:<br=
type=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"quoted-text">On Saturday, January 28, 2017 at 9:25:40 PM UTC-5, Nicol B=
olas wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Rec=
all that <math.h> defines `sin` and `cos` as macros, not functions. T=
hat makes it potentially problematic to use them as member names.<br></div>=
</blockquote></div><div><br>Function-like macros, not object-like macros, w=
hich means the macro expansion only triggers on <span style=3D"color:rgb(20=
4,0,0)"><span style=3D"font-family:courier new,monospace">sin(</span></span=
> or <span style=3D"color:rgb(204,0,0)"><span style=3D"font-family:courier =
new,monospace">cos(</span></span>, which is not a problem in this particula=
r situation.<br></div></div></blockquote></div></div></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">A conforming C++ implementation is required t=
o provide only functions and not macros here.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div></div></div><div class=3D"q=
uoted-text">
<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" 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/f896792a-bd29-4311-a8b0-29c619bfca3d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f896=
792a-bd29-4311-<wbr>a8b0-29c619bfca3d%40isocpp.org</a><wbr>.<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/CAOfiQq%3D1igUrh48MjTW%2BmpZg2kX2MqUf=
t0iaV8_7zigN1Wrmsw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3D1ig=
Urh48MjTW%2BmpZg2kX2MqUft0iaV8_7zigN1Wrmsw%40mail.gmail.com</a>.<br />
--001a1147c6c84fe96c054739ab34--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 29 Jan 2017 07:53:21 -0800 (PST)
Raw View
------=_Part_1148_687993379.1485705201434
Content-Type: multipart/alternative;
boundary="----=_Part_1149_503954141.1485705201434"
------=_Part_1149_503954141.1485705201434
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B41=E6=9C=8829=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 UTC=
+8=E4=B8=8B=E5=8D=887:04:58=EF=BC=8CRichard Smith=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On 28 Jan 2017 8:34 pm, "Chris Hallock" <christoph...@gmail.com=20
> <javascript:>> wrote:
>
> On Saturday, January 28, 2017 at 9:25:40 PM UTC-5, Nicol Bolas wrote:
>
>> Recall that <math.h> defines `sin` and `cos` as macros, not functions.=
=20
>> That makes it potentially problematic to use them as member names.
>>
>
> Function-like macros, not object-like macros, which means the macro=20
> expansion only triggers on sin( or cos(, which is not a problem in this=
=20
> particular situation.
>
>
> A conforming C++ implementation is required to provide only functions and=
=20
> not macros here.
>
> This is required for <cmath>. Is it also applied to <math.h>?=20
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f896792a-bd2=
9-4311-a8b0-29c619bfca3d%40isocpp.org=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f896792a-bd=
29-4311-a8b0-29c619bfca3d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
>
>
--=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/58b18251-f228-4c5d-91c7-3da4f4064e45%40isocpp.or=
g.
------=_Part_1149_503954141.1485705201434
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B41=E6=9C=8829=E6=97=A5=E6=98=
=9F=E6=9C=9F=E6=97=A5 UTC+8=E4=B8=8B=E5=8D=887:04:58=EF=BC=8CRichard Smith=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"auto"><div><div><div class=3D"gmail_quote">On 28 Jan 2017 8:34 pm,=
"Chris Hallock" <<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"4FiyouGPAwAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javas=
cript:';return true;">christoph...@gmail.com</a>> wrote:<br type=3D"=
attribution"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div>On Saturday, January 28, 2017 a=
t 9:25:40 PM UTC-5, Nicol Bolas wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">Recall that <math.h> defines `sin` and `cos` =
as macros, not functions. That makes it potentially problematic to use them=
as member names.<br></div></blockquote></div><div><br>Function-like macros=
, not object-like macros, which means the macro expansion only triggers on =
<span style=3D"color:rgb(204,0,0)"><span style=3D"font-family:courier new,m=
onospace">sin(</span></span> or <span style=3D"color:rgb(204,0,0)"><span st=
yle=3D"font-family:courier new,monospace">cos(</span></span>, which is not =
a problem in this particular situation.<br></div></div></blockquote></div><=
/div></div><div dir=3D"auto"><br></div><div dir=3D"auto">A conforming C++ i=
mplementation is required to provide only functions and not macros here.</d=
iv><div dir=3D"auto"><br></div></div></blockquote><div>This is required for=
<cmath>. Is it also applied to <math.h>? <br></div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div dir=3D"auto"></div=
><div dir=3D"auto"><div><div class=3D"gmail_quote"><blockquote style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
4FiyouGPAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"4FiyouGPAwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/f896792a-bd29-4311-a8b0-29c619bfca3d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/f896792a-bd29-4311-a8b0-29c619bfca3d%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/f896792a-bd29-4311-a8b0-29c619bfca3d%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f896792a-bd29-4311-<wbr>a8b0-=
29c619bfca3d%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div></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/58b18251-f228-4c5d-91c7-3da4f4064e45%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/58b18251-f228-4c5d-91c7-3da4f4064e45=
%40isocpp.org</a>.<br />
------=_Part_1149_503954141.1485705201434--
------=_Part_1148_687993379.1485705201434--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 29 Jan 2017 10:06:30 -0800
Raw View
--001a114714602e225605473f9046
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 29 January 2017 at 07:53, FrankHB1989 <frankhb1989@gmail.com> wrote:
> =E5=9C=A8 2017=E5=B9=B41=E6=9C=8829=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 U=
TC+8=E4=B8=8B=E5=8D=887:04:58=EF=BC=8CRichard Smith=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> On 28 Jan 2017 8:34 pm, "Chris Hallock" <christoph...@gmail.com> wrote:
>>
>> On Saturday, January 28, 2017 at 9:25:40 PM UTC-5, Nicol Bolas wrote:
>>
>>> Recall that <math.h> defines `sin` and `cos` as macros, not functions.
>>> That makes it potentially problematic to use them as member names.
>>>
>>
>> Function-like macros, not object-like macros, which means the macro
>> expansion only triggers on sin( or cos(, which is not a problem in this
>> particular situation.
>>
>>
>> A conforming C++ implementation is required to provide only functions an=
d
>> not macros here.
>>
>> This is required for <cmath>. Is it also applied to <math.h>?
>
Yes. See [depr.c.headers]/4 for the specification of C++'s <math.h>.
> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposal...@isocpp.org.
>> To post to this group, send email to std-pr...@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/f896792a-bd29-4311-a8b0-
>> 29c619bfca3d%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f896792a-b=
d29-4311-a8b0-29c619bfca3d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>>
>> --
> 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/58b18251-f228-4c5d-
> 91c7-3da4f4064e45%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58b18251-f2=
28-4c5d-91c7-3da4f4064e45%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAOfiQq%3DMZhRy1qgjK0Lfx6e7fn2xC7b4gOR6Ljj-1M8cP=
i-dHg%40mail.gmail.com.
--001a114714602e225605473f9046
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 2=
9 January 2017 at 07:53, FrankHB1989 <span dir=3D"ltr"><<a href=3D"mailt=
o:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 20=
17=E5=B9=B41=E6=9C=8829=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 UTC+8=E4=B8=8B=
=E5=8D=887:04:58=EF=BC=8CRichard Smith=E5=86=99=E9=81=93=EF=BC=9A<span clas=
s=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div><div>=
<div class=3D"gmail_quote">On 28 Jan 2017 8:34 pm, "Chris Hallock"=
; <<a rel=3D"nofollow">christoph...@gmail.com</a>> wrote:<br type=3D"=
attribution"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div>On Saturday, January 28, 2017 a=
t 9:25:40 PM UTC-5, Nicol Bolas wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">Recall that <math.h> defines `sin` and `cos` =
as macros, not functions. That makes it potentially problematic to use them=
as member names.<br></div></blockquote></div><div><br>Function-like macros=
, not object-like macros, which means the macro expansion only triggers on =
<span style=3D"color:rgb(204,0,0)"><span style=3D"font-family:courier new,m=
onospace">sin(</span></span> or <span style=3D"color:rgb(204,0,0)"><span st=
yle=3D"font-family:courier new,monospace">cos(</span></span>, which is not =
a problem in this particular situation.<br></div></div></blockquote></div><=
/div></div><div dir=3D"auto"><br></div><div dir=3D"auto">A conforming C++ i=
mplementation is required to provide only functions and not macros here.</d=
iv><div dir=3D"auto"><br></div></div></blockquote></span><div>This is requi=
red for <cmath>. Is it also applied to <math.h>? <br></div></di=
v></blockquote><div><br></div><div>Yes. See [depr.c.headers]/4 for the spec=
ification of C++'s <math.h>.=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"auto"><div dir=3D"auto"></div><div dir=3D"auto"><div><div clas=
s=3D"gmail_quote"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div></div></div><div><span cla=
ss=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></div><span class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f896792a-bd29-4311-a8b0-29c619bfca3d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/f896792a-bd29-4311-a8b0-<wbr>29c619bfca3d%40isocpp.org</a>.<br=
>
</span></blockquote></div><br></div></div></div>
</blockquote></div><span class=3D"">
<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" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/58b18251-f228-4c5d-91c7-3da4f4064e45%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/58b1=
8251-f228-4c5d-<wbr>91c7-3da4f4064e45%40isocpp.org</a><wbr>.<br>
</blockquote></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/CAOfiQq%3DMZhRy1qgjK0Lfx6e7fn2xC7b4gO=
R6Ljj-1M8cPi-dHg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DMZhRy=
1qgjK0Lfx6e7fn2xC7b4gOR6Ljj-1M8cPi-dHg%40mail.gmail.com</a>.<br />
--001a114714602e225605473f9046--
.
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Wed, 1 Feb 2017 09:09:39 +0100
Raw View
On Sunday 29 January 2017 03:25:40 Nicol Bolas wrote:
> While in general I might agree that a struct is usually more
> self-descriptive at the point of use, for this specific case, I have to
> disagree.
>
> The very name of the function "sincos" tells you exactly what it returns
> and in what order it returns them. As such, there is nothing at all
> confusing about:
>
> auto var = std::sincos(...);
> doSomething(var.first);
>
> It's abundantly clear to everyone exactly what is going on.
>
> Like I said, I agree in general that structs are more clear than tuples
> for multiple return values. But with this case, it's just too obvious
> what's going on to bother with it.
Some comments that Lawrence sent me from the std meeting indicate that
std::pair here is problematic also for it's dependency on <utility>.
That alone is a killer argument against pair.
But let me address your argument about pair being "abundantly clear" here,
too. This is only valid as long as the call site is sufficiently close to the
use site. Once you return the result from a nested call chain of auto-
returning functions, or you put a few dozen LOC between the call to sincos()
and the use of the result (yes, _we_ never write functions more than a dozen
lines long, but _others_ do :), .first returns to being totally opaque.
There's simply no reason to use pair in new API. That unnameable struct (is
there an official name for this construct already?) is so much clearer, and
avoids the dependency on <utility>.
If we add something to C++ today, it should not use TR1-level features, but
exploit C++17. That means no std::tie, but structured bindings (which work on
structs, as much as I dislike them), and unnameable structs instead of tuples.
Thanks,
Marc
--
Marc Mutz <marc.mutz@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 1 Feb 2017 12:54:53 -0500
Raw View
On 2017-02-01 03:09, Marc Mutz wrote:
> If we add something to C++ today, it should not use TR1-level features, but
> exploit C++17. That means no std::tie, but structured bindings (which work on
> structs, as much as I dislike them), and unnameable structs instead of tuples.
Strongly agreed. And in case anyone wants to protest that this precludes
a forward declaration of the function, well, please vote for D0536 ;-).
(https://github.com/mwoehlke/cpp-proposals/blob/master/p0536r0-implicit-return-and-anonymous-structs.rst)
--
Matthew
--
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/589220ED.7040801%40gmail.com.
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 5 Feb 2017 03:11:31 -0800 (PST)
Raw View
------=_Part_4337_110010867.1486293091104
Content-Type: multipart/alternative;
boundary="----=_Part_4338_1247085107.1486293091105"
------=_Part_4338_1247085107.1486293091105
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B41=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8A=E5=8D=882:06:53=EF=BC=8CRichard Smith=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On 29 January 2017 at 07:53, FrankHB1989 <frank...@gmail.com <javascript:=
>
> > wrote:
>
>> =E5=9C=A8 2017=E5=B9=B41=E6=9C=8829=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 =
UTC+8=E4=B8=8B=E5=8D=887:04:58=EF=BC=8CRichard Smith=E5=86=99=E9=81=93=EF=
=BC=9A
>>>
>>> On 28 Jan 2017 8:34 pm, "Chris Hallock" <christoph...@gmail.com> wrote:
>>>
>>> On Saturday, January 28, 2017 at 9:25:40 PM UTC-5, Nicol Bolas wrote:
>>>
>>>> Recall that <math.h> defines `sin` and `cos` as macros, not functions.=
=20
>>>> That makes it potentially problematic to use them as member names.
>>>>
>>>
>>> Function-like macros, not object-like macros, which means the macro=20
>>> expansion only triggers on sin( or cos(, which is not a problem in this=
=20
>>> particular situation.
>>>
>>>
>>> A conforming C++ implementation is required to provide only functions=
=20
>>> and not macros here.
>>>
>>> This is required for <cmath>. Is it also applied to <math.h>?=20
>>
>
> Yes. See [depr.c.headers]/4 for the specification of C++'s <math.h>.=20
>
I don't find this requirement in [depr.c.headers] in N4618. Particularly,=
=20
<math.h> is not covered by [headers], and [depr.c.headers]/4 only mentions=
=20
"names" but no "macro names" or something like note on [header]/6 at all.
=20
> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f896792a-b=
d29-4311-a8b0-29c619bfca3d%40isocpp.org=20
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f896792a-=
bd29-4311-a8b0-29c619bfca3d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>>
>>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58b18251-f2=
28-4c5d-91c7-3da4f4064e45%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58b18251-f=
228-4c5d-91c7-3da4f4064e45%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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/7d530400-9fdc-4528-b98b-2b0722c718d4%40isocpp.or=
g.
------=_Part_4338_1247085107.1486293091105
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B41=E6=9C=8830=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8A=E5=8D=882:06:53=EF=BC=8CRichard Smith=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On 29 January 2017 at 07:53, =
FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"m8RnhOemAwAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">frank...@gmail.com</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2017=E5=B9=B41=E6=
=9C=8829=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 UTC+8=E4=B8=8B=E5=8D=887:04:58=
=EF=BC=8CRichard Smith=E5=86=99=E9=81=93=EF=BC=9A<span><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"auto"><div><div><div class=3D"gmail_quote">=
On 28 Jan 2017 8:34 pm, "Chris Hallock" <<a rel=3D"nofollow">c=
hristoph...@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div>On Saturday, January 28, 2017 at 9:25:40 PM UTC-5, Nicol B=
olas wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Rec=
all that <math.h> defines `sin` and `cos` as macros, not functions. T=
hat makes it potentially problematic to use them as member names.<br></div>=
</blockquote></div><div><br>Function-like macros, not object-like macros, w=
hich means the macro expansion only triggers on <span style=3D"color:rgb(20=
4,0,0)"><span style=3D"font-family:courier new,monospace">sin(</span></span=
> or <span style=3D"color:rgb(204,0,0)"><span style=3D"font-family:courier =
new,monospace">cos(</span></span>, which is not a problem in this particula=
r situation.<br></div></div></blockquote></div></div></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">A conforming C++ implementation is required t=
o provide only functions and not macros here.</div><div dir=3D"auto"><br></=
div></div></blockquote></span><div>This is required for <cmath>. Is i=
t also applied to <math.h>? <br></div></div></blockquote><div><br></d=
iv><div>Yes. See [depr.c.headers]/4 for the specification of C++'s <=
math.h>.=C2=A0</div></div></div></div></blockquote><div><br>I don't =
find this requirement in [depr.c.headers] in N4618. Particularly, <math.=
h> is not covered by [headers], and [depr.c.headers]/4 only mentions &qu=
ot;names" but no "macro names" or something like note on [he=
ader]/6 at all.<br>=C2=A0<br></div><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"><div><div class=3D"gmail_quote"><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"auto"><div dir=3D"auto"></div><div dir=3D"auto"><div><div c=
lass=3D"gmail_quote"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div></div><div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></div><span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f896792a-bd29-4311-a8b0-29c619bfca3d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/f896792a-bd29-4311-a8b0-29c619bfca3d%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/f896792a-bd29-4311-a8b0-29c619bfca3d%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f896792a-bd29-4311-<wbr>a8b0-=
29c619bfca3d%40isocpp.org</a><wbr>.<br>
</span></blockquote></div><br></div></div></div>
</blockquote></div><span>
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
m8RnhOemAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"m8RnhOemAwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/58b18251-f228-4c5d-91c7-3da4f4064e45%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/58b18251-f228-4c5d-91c7-3da4f4064e45%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/58b18251-f228-4c5d-91c7-3da4f4064e45%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/58b18251-f228-4c5d-<wbr>91c7-=
3da4f4064e45%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></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/7d530400-9fdc-4528-b98b-2b0722c718d4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7d530400-9fdc-4528-b98b-2b0722c718d4=
%40isocpp.org</a>.<br />
------=_Part_4338_1247085107.1486293091105--
------=_Part_4337_110010867.1486293091104--
.
Author: Chris Hallock <christopherhallock@gmail.com>
Date: Sun, 5 Feb 2017 11:43:29 -0800 (PST)
Raw View
------=_Part_414_2109867844.1486323809944
Content-Type: multipart/alternative;
boundary="----=_Part_415_222011960.1486323809945"
------=_Part_415_222011960.1486323809945
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, February 5, 2017 at 6:11:31 AM UTC-5, FrankHB1989 wrote:
> =E5=9C=A8 2017=E5=B9=B41=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 U=
TC+8=E4=B8=8A=E5=8D=882:06:53=EF=BC=8CRichard Smith=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> On 29 January 2017 at 07:53, FrankHB1989 <frank...@gmail.com> wrote:
>>
>>> =E5=9C=A8 2017=E5=B9=B41=E6=9C=8829=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5=
UTC+8=E4=B8=8B=E5=8D=887:04:58=EF=BC=8CRichard Smith=E5=86=99=E9=81=93=EF=
=BC=9A
>>>>
>>>> On 28 Jan 2017 8:34 pm, "Chris Hallock" <christoph...@gmail.com> wrote=
:
>>>>
>>>> On Saturday, January 28, 2017 at 9:25:40 PM UTC-5, Nicol Bolas wrote:
>>>>
>>>>> Recall that <math.h> defines `sin` and `cos` as macros, not functions=
..=20
>>>>> That makes it potentially problematic to use them as member names.
>>>>>
>>>>
>>>> Function-like macros, not object-like macros, which means the macro=20
>>>> expansion only triggers on sin( or cos(, which is not a problem in=20
>>>> this particular situation.
>>>>
>>>>
>>>> A conforming C++ implementation is required to provide only functions=
=20
>>>> and not macros here.
>>>>
>>>> This is required for <cmath>. Is it also applied to <math.h>?=20
>>>
>>
>> Yes. See [depr.c.headers]/4 for the specification of C++'s <math.h>.=20
>>
>
> I don't find this requirement in [depr.c.headers] in N4618. Particularly,=
=20
> <math.h> is not covered by [headers], and [depr.c.headers]/4 only mention=
s=20
> "names" but no "macro names" or something like note on [header]/6 at all.
>
See also [res.on.headers]/3 <http://eel.is/c++draft/res.on.headers#3>: "The=
=20
C standard library headers ([depr.c.headers]=20
<http://eel.is/c++draft/depr.c.headers>) shall include only their=20
corresponding C++ standard library header, as described in [headers]=20
<http://eel.is/c++draft/headers>."
--=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/95b7f5fd-bb7c-46f3-889a-1729edb4dd5b%40isocpp.or=
g.
------=_Part_415_222011960.1486323809945
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, February 5, 2017 at 6:11:31 AM UTC-5, FrankHB19=
89 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
=E5=9C=A8 2017=E5=B9=B41=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8A=E5=8D=882:06:53=EF=BC=8CRichard Smith=E5=86=99=E9=81=93=EF=BC=
=9A<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On 29 January 2017 at 07:53, FrankHB1989 <span dir=3D"ltr"=
><<a rel=3D"nofollow">frank...@gmail.com</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2017=E5=B9=B41=E6=9C=88=
29=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 UTC+8=E4=B8=8B=E5=8D=887:04:58=EF=BC=
=8CRichard Smith=E5=86=99=E9=81=93=EF=BC=9A<span><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"auto"><div><div><div class=3D"gmail_quote">On 28 =
Jan 2017 8:34 pm, "Chris Hallock" <<a rel=3D"nofollow">christo=
ph...@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div>On Saturday, January 28, 2017 at 9:25:40 PM UTC-5, Nicol Bolas w=
rote:<br><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">Recall th=
at <math.h> defines `sin` and `cos` as macros, not functions. That ma=
kes it potentially problematic to use them as member names.<br></div></bloc=
kquote></div><div><br>Function-like macros, not object-like macros, which m=
eans the macro expansion only triggers on <span style=3D"color:rgb(204,0,0)=
"><span style=3D"font-family:courier new,monospace">sin(</span></span> or <=
span style=3D"color:rgb(204,0,0)"><span style=3D"font-family:courier new,mo=
nospace">cos(</span></span>, which is not a problem in this particular situ=
ation.<br></div></div></blockquote></div></div></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">A conforming C++ implementation is required to prov=
ide only functions and not macros here.</div><div dir=3D"auto"><br></div></=
div></blockquote></span><div>This is required for <cmath>. Is it also=
applied to <math.h>? <br></div></div></blockquote><div><br></div><di=
v>Yes. See [depr.c.headers]/4 for the specification of C++'s <math.h=
>.=C2=A0</div></div></div></div></blockquote><div><br>I don't find t=
his requirement in [depr.c.headers] in N4618. Particularly, <math.h> =
is not covered by [headers], and [depr.c.headers]/4 only mentions "nam=
es" but no "macro names" or something like note on [header]/=
6 at all.<br></div></div></blockquote><div><br>See also <a href=3D"http://e=
el.is/c++draft/res.on.headers#3">[res.on.headers]/3</a>: "The C standa=
rd library headers (<a href=3D"http://eel.is/c++draft/depr.c.headers">[depr=
..c.headers]</a>)
shall include only their corresponding C++ standard library header,
as described in <a href=3D"http://eel.is/c++draft/headers">[headers]</a>.&q=
uot;</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/95b7f5fd-bb7c-46f3-889a-1729edb4dd5b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/95b7f5fd-bb7c-46f3-889a-1729edb4dd5b=
%40isocpp.org</a>.<br />
------=_Part_415_222011960.1486323809945--
------=_Part_414_2109867844.1486323809944--
.
Author: 3dw4rd@verizon.net
Date: Tue, 21 Feb 2017 15:31:49 -0800 (PST)
Raw View
------=_Part_1750_2005631028.1487719909531
Content-Type: multipart/alternative;
boundary="----=_Part_1751_2055430751.1487719909531"
------=_Part_1751_2055430751.1487719909531
Content-Type: text/plain; charset=UTF-8
+1 for a narrow type.
Look at div_t and other things.
(Unfortunately std::div_t is not template as it really should be.
I don't know if it would be legal to
using lldiv_t = div_t<long>?)
I would suggest
template<typename _Real>
sincos_t
{
_Real sin_value;
_Real cos_value;
};
Or sin_v/cos_v;
As a struct this would still play nicely with decomposition:
auto[sphi, cphi] = std::sincos(phi);
This would allow you to teach other functions to intelligently take
sincos_t instead of pair:
std::atan(const sincos_t&); // Like atan2.
std::complex::complex(const sincos_t&); // Like polar(1, phi);
etc.
--
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/dbf32e97-2d23-4b60-b098-856b1b2e075d%40isocpp.org.
------=_Part_1751_2055430751.1487719909531
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>+1 for a narrow type.<br><br>Look at div_t and other t=
hings.<br><span class=3D"mw-geshi cpp source-cpp">(Unfortunately std<span c=
lass=3D"sy4">::</span><span class=3D"me2">div_t is not template as it reall=
y should be.<br>I don't know if it would be legal to<br>using lldiv_t =
=3D div_t<long>?)<br><br></span></span>I would suggest<br><br>templat=
e<typename _Real><br>=C2=A0 sincos_t<br>=C2=A0 {<br>=C2=A0=C2=A0=C2=
=A0 _Real sin_value;<br>=C2=A0=C2=A0=C2=A0 _Real cos_value;<br>=C2=A0 };<br=
><br>Or sin_v/cos_v;<br>As a struct this would still play nicely with decom=
position:<br><br>auto[sphi, cphi] =3D std::sincos(phi);<br><br>This would a=
llow you to teach other functions to intelligently take sincos_t instead of=
pair:<br>std::atan(const sincos_t&); // Like atan2.<br>std::complex::c=
omplex(const sincos_t&); // Like polar(1, phi);<br><br>etc.<br><br></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/dbf32e97-2d23-4b60-b098-856b1b2e075d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dbf32e97-2d23-4b60-b098-856b1b2e075d=
%40isocpp.org</a>.<br />
------=_Part_1751_2055430751.1487719909531--
------=_Part_1750_2005631028.1487719909531--
.
Author: 3dw4rd@verizon.net
Date: Wed, 22 Feb 2017 11:21:14 -0800 (PST)
Raw View
------=_Part_1937_1809242087.1487791274751
Content-Type: multipart/alternative;
boundary="----=_Part_1938_1551475906.1487791274752"
------=_Part_1938_1551475906.1487791274752
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 21, 2017 at 6:31:49 PM UTC-5, 3dw...@verizon.net wrote:
>
>
> +1 for a narrow type.
>
> Look at div_t and other things.
> (Unfortunately std::div_t is not template as it really should be.
> I don't know if it would be legal to
> using lldiv_t = div_t<long>?)
>
> I would suggest
>
> template<typename _Real>
> sincos_t
> {
> _Real sin_value;
> _Real cos_value;
> };
>
> Or sin_v/cos_v;
> As a struct this would still play nicely with decomposition:
>
> auto[sphi, cphi] = std::sincos(phi);
>
> This would allow you to teach other functions to intelligently take
> sincos_t instead of pair:
> std::atan(const sincos_t&); // Like atan2.
> std::complex::complex(const sincos_t&); // Like polar(1, phi);
>
> etc.
>
>
Ok, I'm slow.
If I need to capture the type for a while I just
decltype(std::sincos(phi));
This raises an interesting question though (above this thread) you still
have to know what's in there to some extent? And how many? Maybe?
std::atan(const decltype(std::sincos(double()))& sc)
{
const auto& [s, c] = sc;
return atan2(s, c);
}
I'm just trying to get my head around how things are supposed to look in
the new world order.
--
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/cf04016e-dc7e-4343-b438-23b74c62e1fe%40isocpp.org.
------=_Part_1938_1551475906.1487791274752
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, February 21, 2017 at 6:31:49 PM UTC-5,=
3dw...@verizon.net 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>+1 for a narrow type.<br><br>Look at div_t and other thing=
s.<br><span>(Unfortunately std<span>::</span><span>div_t is not template as=
it really should be.<br>I don't know if it would be legal to<br>using =
lldiv_t =3D div_t<long>?)<br><br></span></span>I would suggest<br><br=
>template<typename _Real><br>=C2=A0 sincos_t<br>=C2=A0 {<br>=C2=A0=C2=
=A0=C2=A0 _Real sin_value;<br>=C2=A0=C2=A0=C2=A0 _Real cos_value;<br>=C2=A0=
};<br><br>Or sin_v/cos_v;<br>As a struct this would still play nicely with=
decomposition:<br><br>auto[sphi, cphi] =3D std::sincos(phi);<br><br>This w=
ould allow you to teach other functions to intelligently take sincos_t inst=
ead of pair:<br>std::atan(const sincos_t&); // Like atan2.<br>std::comp=
lex::complex(const sincos_t&); // Like polar(1, phi);<br><br>etc.<br><b=
r></div></blockquote><div><br>Ok, I'm slow.<br><br>If I need to capture=
the type for a while I just<br>decltype(std::sincos(phi));<br><br>This rai=
ses an interesting question though (above this thread) you still have to kn=
ow what's in there to some extent? And how many? Maybe?<br><br><div sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; overflow-wrap: break-word;" clas=
s=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><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-prettify">atan</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">decltype</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">sincos</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=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: #000;" class=3D"styled-by-prettify"> sc</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify"></span></code>auto</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">]</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> sc</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> atan2</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br></span></div></code></div><br><br>I'm just t=
rying to get my head around how things are supposed to look in the new worl=
d order.<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/cf04016e-dc7e-4343-b438-23b74c62e1fe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cf04016e-dc7e-4343-b438-23b74c62e1fe=
%40isocpp.org</a>.<br />
------=_Part_1938_1551475906.1487791274752--
------=_Part_1937_1809242087.1487791274751--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 22 Feb 2017 15:20:42 -0500
Raw View
On 2017-02-22 14:21, 3dw4rd@verizon.net wrote:
> If I need to capture the type for a while I just
> decltype(std::sincos(phi));
Incidentally:
template <typename T> using sincos_t =
decltype(std::sincos(std::declval<T>());
> This raises an interesting question though (above this thread) you still
> have to know what's in there to some extent? And how many? Maybe?
>
> std::atan(const decltype(std::sincos(double()))& sc)
> {
> const auto& [s, c] = sc;
> return atan2(s, c);
> }
>
> I'm just trying to get my head around how things are supposed to look in
> the new world order.
With the original proposal, yes, that's what you'd have to do (or use
the alias, above). Given your previous comments, I'm liking the idea of
having a "proper" type much better, though.
--
Matthew
--
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/58ADF29A.50805%40gmail.com.
.
Author: 3dw4rd@verizon.net
Date: Mon, 6 Mar 2017 14:35:03 -0800 (PST)
Raw View
------=_Part_1715_237227814.1488839703540
Content-Type: multipart/alternative;
boundary="----=_Part_1716_1478966266.1488839703540"
------=_Part_1716_1478966266.1488839703540
Content-Type: text/plain; charset=UTF-8
>
> With the original proposal, yes, that's what you'd have to do (or use
> the alias, above). Given your previous comments, I'm liking the idea of
> having a "proper" type much better, though.
>
> --
> Matthew
>
Stepping up to a higher level than this particular paper for a minute.
This idea of return by anonymous struct idea has me worried about
discoverability and documentation.
How are these and tools that support them supposed to work in the new world?
It seems like we might really need static reflection for this if nothing
else.
Just a thought.
--
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/d66b10ac-c998-4353-b886-d66b8754b4db%40isocpp.org.
------=_Part_1716_1478966266.1488839703540
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>With the original proposal, yes, that's what you'd have to do (=
or use
<br>the alias, above). Given your previous comments, I'm liking the ide=
a of
<br>having a "proper" type much better, though.
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br>Stepping up to a higher level than this particula=
r paper for a minute.<br>This idea of return by anonymous struct idea has m=
e worried about discoverability and documentation.<br>How are these and too=
ls that support them supposed to work in the new world?<br>It seems like we=
might really need static reflection for this if nothing else.<br>Just a th=
ought.<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/d66b10ac-c998-4353-b886-d66b8754b4db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d66b10ac-c998-4353-b886-d66b8754b4db=
%40isocpp.org</a>.<br />
------=_Part_1716_1478966266.1488839703540--
------=_Part_1715_237227814.1488839703540--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 6 Mar 2017 14:50:35 -0800 (PST)
Raw View
------=_Part_6_378190772.1488840635733
Content-Type: multipart/alternative;
boundary="----=_Part_7_1689890495.1488840635733"
------=_Part_7_1689890495.1488840635733
Content-Type: text/plain; charset=UTF-8
On Monday, March 6, 2017 at 5:35:03 PM UTC-5, 3dw...@verizon.net wrote:
>
>
>
>> With the original proposal, yes, that's what you'd have to do (or use
>> the alias, above). Given your previous comments, I'm liking the idea of
>> having a "proper" type much better, though.
>>
>> --
>> Matthew
>>
>
> Stepping up to a higher level than this particular paper for a minute.
> This idea of return by anonymous struct idea has me worried about
> discoverability and documentation.
> How are these and tools that support them supposed to work in the new
> world?
> It seems like we might really need static reflection for this if nothing
> else.
>
"Need static reflection" to do what, exactly? Structured binding doesn't
need it. Using it directly by member names doesn't need it (you just use
`auto`). So what exactly would I be doing, where I need to reflect over the
return type of such a function?
What is the "discoverability" problem of `struct {T sin, T cos}
sincos(...)`? It seems to spell out exactly what it does. How is that
difficult to document? I wouldn't even feel the need to document that
beyond "returns the sine and cosine of the provided value".
Can you give examples of where someone would want to use an anonymous
struct as a return value, and the use of that struct would not be obvious
(or made obvious by naming the parameters well)?
Now, I do agree with one point: people probably *want* to use anonymous
return structs more often than they *should*. Most return values should be
a specific, named type, and the places where people really do need one-shot
bundles of values is quite rare.
But for one-off cases where anonymous return structs are appropriate...
what's the problem?
--
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/acfef564-0dda-4267-800f-0f4abe869b62%40isocpp.org.
------=_Part_7_1689890495.1488840635733
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, March 6, 2017 at 5:35:03 PM UTC-5, 3dw.=
...@verizon.net wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>With the original proposal, yes, that's what you'd have to do (=
or use
<br>the alias, above). Given your previous comments, I'm liking the ide=
a of
<br>having a "proper" type much better, though.
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br>Stepping up to a higher level than this particula=
r paper for a minute.<br>This idea of return by anonymous struct idea has m=
e worried about discoverability and documentation.<br>How are these and too=
ls that support them supposed to work in the new world?<br>It seems like we=
might really need static reflection for this if nothing else.<br></div></d=
iv></blockquote><div><br>"Need static reflection" to do what, exa=
ctly? Structured binding doesn't need it. Using it directly by member n=
ames doesn't need it (you just use `auto`). So what exactly would I be =
doing, where I need to reflect over the return type of such a function?<br>=
<br>What is the "discoverability" problem of `struct {T sin, T co=
s} sincos(...)`? It seems to spell out exactly what it does. How is that di=
fficult to document? I wouldn't even feel the need to document that bey=
ond "returns the sine and cosine of the provided value".<br><br>C=
an you give examples of where someone would want to use an anonymous struct=
as a return value, and the use of that struct would not be obvious (or mad=
e obvious by naming the parameters well)?<br><br>Now, I do agree with one p=
oint: people probably <i>want</i> to use anonymous return structs more ofte=
n than they <i>should</i>. Most return values should be a specific, named t=
ype, and the places where people really do need one-shot bundles of values =
is quite rare.<br><br>But for one-off cases where anonymous return structs =
are appropriate... what's the problem?<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/acfef564-0dda-4267-800f-0f4abe869b62%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/acfef564-0dda-4267-800f-0f4abe869b62=
%40isocpp.org</a>.<br />
------=_Part_7_1689890495.1488840635733--
------=_Part_6_378190772.1488840635733--
.
Author: 3dw4rd@verizon.net
Date: Tue, 7 Mar 2017 09:34:45 -0800 (PST)
Raw View
------=_Part_886_1442104375.1488908086110
Content-Type: multipart/alternative;
boundary="----=_Part_887_222667344.1488908086111"
------=_Part_887_222667344.1488908086111
Content-Type: text/plain; charset=UTF-8
"Need static reflection" to do what, exactly? Structured binding doesn't
need it. Using it directly by member names doesn't need it (you just use
`auto`). So what exactly would I be doing, where I need to reflect over the
return type of such a function?
>
> What is the "discoverability" problem of `struct {T sin, T cos}
> sincos(...)`? It seems to spell out exactly what it does. How is that
> difficult to document? I wouldn't even feel the need to document that
> beyond "returns the sine and cosine of the provided value".
>
> Can you give examples of where someone would want to use an anonymous
> struct as a return value, and the use of that struct would not be obvious
> (or made obvious by naming the parameters well)?
>
> Now, I do agree with one point: people probably *want* to use anonymous
> return structs more often than they *should*. Most return values should
> be a specific, named type, and the places where people really do need
> one-shot bundles of values is quite rare.
>
> But for one-off cases where anonymous return structs are appropriate...
> what's the problem?
>
I'm probably worrying too much. Every feature can be abused of course.
Certainly for sincos it's pretty obvious. I was just worrying about some
undocumented anonymous struct with nontrivial semantics leaking out into
the world. But that's probably not worth worrying about. That's a design
problem.
--
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/60eac6c1-6d1b-4182-a7e8-721be68d4b25%40isocpp.org.
------=_Part_887_222667344.1488908086111
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>"Need static reflection" to do what, exactly=
? Structured binding doesn't need it. Using it directly by member names=
doesn't need it (you just use `auto`). So what exactly would I be doin=
g, where I need to reflect over the return type of such a function?<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>What is =
the "discoverability" problem of `struct {T sin, T cos} sincos(..=
..)`? It seems to spell out exactly what it does. How is that difficult to d=
ocument? I wouldn't even feel the need to document that beyond "re=
turns the sine and cosine of the provided value".<br><br>Can you give =
examples of where someone would want to use an anonymous struct as a return=
value, and the use of that struct would not be obvious (or made obvious by=
naming the parameters well)?<br><br>Now, I do agree with one point: people=
probably <i>want</i> to use anonymous return structs more often than they =
<i>should</i>. Most return values should be a specific, named type, and the=
places where people really do need one-shot bundles of values is quite rar=
e.<br><br>But for one-off cases where anonymous return structs are appropri=
ate... what's the problem?<br></div></div></blockquote><div>=C2=A0<br>I=
'm probably worrying too much.=C2=A0 Every feature can be abused of cou=
rse. Certainly for sincos it's pretty obvious.=C2=A0 I was just worryin=
g about some undocumented anonymous struct with nontrivial semantics leakin=
g out into the world.=C2=A0 But that's probably not worth worrying abou=
t.=C2=A0 That's a design problem.<br><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/60eac6c1-6d1b-4182-a7e8-721be68d4b25%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/60eac6c1-6d1b-4182-a7e8-721be68d4b25=
%40isocpp.org</a>.<br />
------=_Part_887_222667344.1488908086111--
------=_Part_886_1442104375.1488908086110--
.
Author: 3dw4rd@verizon.net
Date: Tue, 7 Mar 2017 09:41:10 -0800 (PST)
Raw View
------=_Part_858_389757688.1488908470823
Content-Type: multipart/alternative;
boundary="----=_Part_859_191840730.1488908470823"
------=_Part_859_191840730.1488908470823
Content-Type: text/plain; charset=UTF-8
>
> I'm probably worrying too much. Every feature can be abused of course.
> Certainly for sincos it's pretty obvious. I was just worrying about some
> undocumented anonymous struct with nontrivial semantics leaking out into
> the world. But that's probably not worth worrying about. That's a design
> problem.
>
>
It occurred to me that decomposability both in degree (number of things)
and in the types of things could be specified with concepts. Just put the
decomp statement in a requires block and have requirements on the bits as
well.
--
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/5776b160-c71b-4540-95e1-e614a64e275c%40isocpp.org.
------=_Part_859_191840730.1488908470823
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>=C2=A0<br>I'm probably worrying too much.=C2=A0 Every fea=
ture can be abused of course. Certainly for sincos it's pretty obvious.=
=C2=A0 I was just worrying about some undocumented anonymous struct with no=
ntrivial semantics leaking out into the world.=C2=A0 But that's probabl=
y not worth worrying about.=C2=A0 That's a design problem.<br><br></div=
></div></blockquote><div><br>It occurred to me that decomposability both in=
degree (number of things) and in the types of things could be specified wi=
th concepts.=C2=A0 Just put the decomp statement in a requires block and ha=
ve requirements on the bits as well.<br><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/5776b160-c71b-4540-95e1-e614a64e275c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5776b160-c71b-4540-95e1-e614a64e275c=
%40isocpp.org</a>.<br />
------=_Part_859_191840730.1488908470823--
------=_Part_858_389757688.1488908470823--
.