Topic: Constexpr function parameters through special conversions
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 26 Apr 2017 12:29:33 -0700 (PDT)
Raw View
------=_Part_6398_633976420.1493234973425
Content-Type: multipart/alternative;
boundary="----=_Part_6399_1714040027.1493234973425"
------=_Part_6399_1714040027.1493234973425
Content-Type: text/plain; charset=UTF-8
Function parameters in `constexpr` functions aren't constexpr; only
non-type template parameters are considered constant expressions. However,
you can approximate `constexpr` parameters through the use of a type:
template<size_t N>
constexpr auto func(std::integral_constant_t<size_t, N>)
{
return std::array<int, N>{};
}
The problem with this is that you have to invoke such a function in a very
unnatural way: `func(std::integral_constant<std::size_t, 20>);` That puts a
lot of noise in the function argument, when what you really want to say is
`func(20);`
What I suggest is making `integral_constant` specially recognized by the
compiler in template argument deduction circumstances. If the given
argument for such a parameter is either an integer literal (with a
non-narrowing conversion to the `integral_constant`'s type) or a constexpr
variable (who's type has a non-narrowing conversion to the
`integral_constant`'s type), then the compiler will deduce the
corresponding `N` as if you had spelled out
`std::integral_constant_t<typename>`. If the type of `integral_constant` is
also deduced (either via C++17's `auto` or as a template parameter), then
this would work as well, simply using the type of the expression.
We could also add more `type_constant` types to the standard library, like
`float_constant`, `pointer_constant`, etc.
One reason I bring this up is that this feels like it's really a part of a
more generic feature, but I can't think of what such a feature might look
like. This looks like some mechanism for customizing how template argument
deduction works, but what would that actually be?
--
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/6eb51b1b-d526-486b-9dc2-6ccd4e9f514d%40isocpp.org.
------=_Part_6399_1714040027.1493234973425
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Function parameters in `constexpr` functions aren't co=
nstexpr; only non-type template parameters are considered constant expressi=
ons. However, you can approximate `constexpr` parameters through the use of=
a type:<br><br><div style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow=
-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">template</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
size_t N</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> func</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">integral_constant_t</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">size_t</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> N</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><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">return</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"colo=
r: #000;" class=3D"styled-by-prettify">array</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> N</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">>{};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</sp=
an></div></code></div><br>The problem with this is that you have to invoke =
such a function in a very unnatural way: `func(std::integral_constant<st=
d::size_t, 20>);` That puts a lot of noise in the function argument, whe=
n what you really want to say is `func(20);`<br><br>What I suggest is makin=
g `integral_constant` specially recognized by the compiler in template argu=
ment deduction circumstances. If the given argument for such a parameter is=
either an integer literal (with a non-narrowing conversion to the `integra=
l_constant`'s type) or a constexpr variable (who's type has a non-n=
arrowing conversion to the `integral_constant`'s type), then the compil=
er will deduce the corresponding `N` as if you had spelled out `std::integr=
al_constant_t<typename>`. If the type of `integral_constant` is also =
deduced (either via C++17's `auto` or as a template parameter), then th=
is would work as well, simply using the type of the expression.<br><br>We c=
ould also add more `type_constant` types to the standard library, like `flo=
at_constant`, `pointer_constant`, etc.<br><br>One reason I bring this up is=
that this feels like it's really a part of a more generic feature, but=
I can't think of what such a feature might look like. This looks like =
some mechanism for customizing how template argument deduction works, but w=
hat would that actually be?<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/6eb51b1b-d526-486b-9dc2-6ccd4e9f514d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6eb51b1b-d526-486b-9dc2-6ccd4e9f514d=
%40isocpp.org</a>.<br />
------=_Part_6399_1714040027.1493234973425--
------=_Part_6398_633976420.1493234973425--
.
Author: John McFarlane <john@mcfarlane.name>
Date: Wed, 26 Apr 2017 20:17:00 +0000
Raw View
--f403045ea9bc874620054e17862a
Content-Type: text/plain; charset=UTF-8
I would also like to be able to do more static work with function
parameters. For example:
auto x = just_wide_enough(100); // returns an int8_t
auto y = just_wide_enough(1000); // returns an int16_t
Note that it is already possible to generate integral_constant from
user-defined literals so `func(20_c)` is a workaround, e.g. [
http://www.boost.org/doc/libs/1_61_0/libs/hana/doc/html/namespaceboost_1_1hana_1_1literals.html#a85ac3c47d02722a334181aab540e732c
].
On Wed, Apr 26, 2017 at 12:29 PM Nicol Bolas <jmckesson@gmail.com> wrote:
> Function parameters in `constexpr` functions aren't constexpr; only
> non-type template parameters are considered constant expressions. However,
> you can approximate `constexpr` parameters through the use of a type:
>
> template<size_t N>
> constexpr auto func(std::integral_constant_t<size_t, N>)
> {
> return std::array<int, N>{};
> }
>
> The problem with this is that you have to invoke such a function in a very
> unnatural way: `func(std::integral_constant<std::size_t, 20>);` That puts a
> lot of noise in the function argument, when what you really want to say is
> `func(20);`
>
> What I suggest is making `integral_constant` specially recognized by the
> compiler in template argument deduction circumstances. If the given
> argument for such a parameter is either an integer literal (with a
> non-narrowing conversion to the `integral_constant`'s type) or a constexpr
> variable (who's type has a non-narrowing conversion to the
> `integral_constant`'s type), then the compiler will deduce the
> corresponding `N` as if you had spelled out
> `std::integral_constant_t<typename>`. If the type of `integral_constant` is
> also deduced (either via C++17's `auto` or as a template parameter), then
> this would work as well, simply using the type of the expression.
>
> We could also add more `type_constant` types to the standard library, like
> `float_constant`, `pointer_constant`, etc.
>
> One reason I bring this up is that this feels like it's really a part of a
> more generic feature, but I can't think of what such a feature might look
> like. This looks like some mechanism for customizing how template argument
> deduction works, but what would that actually be?
>
> --
> 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/6eb51b1b-d526-486b-9dc2-6ccd4e9f514d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6eb51b1b-d526-486b-9dc2-6ccd4e9f514d%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/CABPJVnRi4P94yRi9Hfz%2BQbY2aWQpZfPeBnEEO1dZBLdW90YvjQ%40mail.gmail.com.
--f403045ea9bc874620054e17862a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>I would also like to be able to do more sta=
tic work with function parameters. For example:<br><br></div>auto x =3D jus=
t_wide_enough(100);=C2=A0 // returns an int8_t<br></div>auto y =3D just_wid=
e_enough(1000);=C2=A0 // returns an int16_t<br><br></div>Note that it is al=
ready possible to generate integral_constant from user-defined literals so =
`func(20_c)` is a workaround, e.g. [<a href=3D"http://www.boost.org/doc/lib=
s/1_61_0/libs/hana/doc/html/namespaceboost_1_1hana_1_1literals.html#a85ac3c=
47d02722a334181aab540e732c">http://www.boost.org/doc/libs/1_61_0/libs/hana/=
doc/html/namespaceboost_1_1hana_1_1literals.html#a85ac3c47d02722a334181aab5=
40e732c</a>].<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On W=
ed, Apr 26, 2017 at 12:29 PM Nicol Bolas <<a href=3D"mailto:jmckesson@gm=
ail.com">jmckesson@gmail.com</a>> wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">Function parameters in `constexpr` functions aren=
't constexpr; only non-type template parameters are considered constant=
expressions. However, you can approximate `constexpr` parameters through t=
he use of a type:<br><br><div style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px" class=3D"m=
_8510450737623778691prettyprint"><code class=3D"m_8510450737623778691pretty=
print"><div class=3D"m_8510450737623778691subprettyprint"><span style=3D"co=
lor:#008" class=3D"m_8510450737623778691styled-by-prettify">template</span>=
<span style=3D"color:#660" class=3D"m_8510450737623778691styled-by-prettify=
"><</span><span style=3D"color:#000" class=3D"m_8510450737623778691style=
d-by-prettify">size_t N</span><span style=3D"color:#660" class=3D"m_8510450=
737623778691styled-by-prettify">></span><span style=3D"color:#000" class=
=3D"m_8510450737623778691styled-by-prettify"><br></span><span style=3D"colo=
r:#008" class=3D"m_8510450737623778691styled-by-prettify">constexpr</span><=
span style=3D"color:#000" class=3D"m_8510450737623778691styled-by-prettify"=
> </span><span style=3D"color:#008" class=3D"m_8510450737623778691styled-by=
-prettify">auto</span><span style=3D"color:#000" class=3D"m_851045073762377=
8691styled-by-prettify"> func</span><span style=3D"color:#660" class=3D"m_8=
510450737623778691styled-by-prettify">(</span><span style=3D"color:#000" cl=
ass=3D"m_8510450737623778691styled-by-prettify">std</span><span style=3D"co=
lor:#660" class=3D"m_8510450737623778691styled-by-prettify">::</span><span =
style=3D"color:#000" class=3D"m_8510450737623778691styled-by-prettify">inte=
gral_constant_t</span><span style=3D"color:#660" class=3D"m_851045073762377=
8691styled-by-prettify"><</span><span style=3D"color:#000" class=3D"m_85=
10450737623778691styled-by-prettify">size_t</span><span style=3D"color:#660=
" class=3D"m_8510450737623778691styled-by-prettify">,</span><span style=3D"=
color:#000" class=3D"m_8510450737623778691styled-by-prettify"> N</span><spa=
n style=3D"color:#660" class=3D"m_8510450737623778691styled-by-prettify">&g=
t;)</span><span style=3D"color:#000" class=3D"m_8510450737623778691styled-b=
y-prettify"><br></span><span style=3D"color:#660" class=3D"m_85104507376237=
78691styled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_8510=
450737623778691styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:#=
008" class=3D"m_8510450737623778691styled-by-prettify">return</span><span s=
tyle=3D"color:#000" class=3D"m_8510450737623778691styled-by-prettify"> std<=
/span><span style=3D"color:#660" class=3D"m_8510450737623778691styled-by-pr=
ettify">::</span><span style=3D"color:#000" class=3D"m_8510450737623778691s=
tyled-by-prettify">array</span><span style=3D"color:#660" class=3D"m_851045=
0737623778691styled-by-prettify"><</span><span style=3D"color:#008" clas=
s=3D"m_8510450737623778691styled-by-prettify">int</span><span style=3D"colo=
r:#660" class=3D"m_8510450737623778691styled-by-prettify">,</span><span sty=
le=3D"color:#000" class=3D"m_8510450737623778691styled-by-prettify"> N</spa=
n><span style=3D"color:#660" class=3D"m_8510450737623778691styled-by-pretti=
fy">>{};</span><span style=3D"color:#000" class=3D"m_8510450737623778691=
styled-by-prettify"><br></span><span style=3D"color:#660" class=3D"m_851045=
0737623778691styled-by-prettify">}</span></div></code></div><br>The problem=
with this is that you have to invoke such a function in a very unnatural w=
ay: `func(std::integral_constant<std::size_t, 20>);` That puts a lot =
of noise in the function argument, when what you really want to say is `fun=
c(20);`<br><br>What I suggest is making `integral_constant` specially recog=
nized by the compiler in template argument deduction circumstances. If the =
given argument for such a parameter is either an integer literal (with a no=
n-narrowing conversion to the `integral_constant`'s type) or a constexp=
r variable (who's type has a non-narrowing conversion to the `integral_=
constant`'s type), then the compiler will deduce the corresponding `N` =
as if you had spelled out `std::integral_constant_t<typename>`. If th=
e type of `integral_constant` is also deduced (either via C++17's `auto=
` or as a template parameter), then this would work as well, simply using t=
he type of the expression.<br><br>We could also add more `type_constant` ty=
pes to the standard library, like `float_constant`, `pointer_constant`, etc=
..<br><br>One reason I bring this up is that this feels like it's really=
a part of a more generic feature, but I can't think of what such a fea=
ture might look like. This looks like some mechanism for customizing how te=
mplate argument deduction works, but what would that actually be?<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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6eb51b1b-d526-486b-9dc2-6ccd4e9f514d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6eb51b1b-d526-=
486b-9dc2-6ccd4e9f514d%40isocpp.org</a>.<br>
</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/CABPJVnRi4P94yRi9Hfz%2BQbY2aWQpZfPeBn=
EEO1dZBLdW90YvjQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnRi4P94yR=
i9Hfz%2BQbY2aWQpZfPeBnEEO1dZBLdW90YvjQ%40mail.gmail.com</a>.<br />
--f403045ea9bc874620054e17862a--
.
Author: =?UTF-8?Q?=27Thomas_K=C3=B6ppe=27_via_ISO_C=2B=2B_Standard_=2D_Future_Proposals?= <std-proposals@isocpp.org>
Date: Wed, 26 Apr 2017 13:23:42 -0700 (PDT)
Raw View
------=_Part_79_2068456158.1493238222894
Content-Type: multipart/alternative;
boundary="----=_Part_80_1263958689.1493238222894"
------=_Part_80_1263958689.1493238222894
Content-Type: text/plain; charset=UTF-8
A random thought - how about:
template <auto V> struct c : std::integral_constant<decltype(V), V> {};
Usage:
func(c(10)); // calls func(std::integral_constant<int, 10>)
(This may require a deduction guide, I'm not sure.)
--
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/b30aa444-b246-4527-b264-53abdd1e24ba%40isocpp.org.
------=_Part_80_1263958689.1493238222894
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A random thought - how about:<div><br></div><div>=C2=A0 =
=C2=A0 template <auto V> struct c : std::integral_constant<decltyp=
e(V), V> {};</div><div><br></div><div>Usage:</div><div><br></div><div>=
=C2=A0 =C2=A0 func(c(10)); =C2=A0// calls func(std::integral_constant<in=
t, 10>)</div><div><br></div><div>(This may require a deduction guide, I&=
#39;m not sure.)</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/b30aa444-b246-4527-b264-53abdd1e24ba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b30aa444-b246-4527-b264-53abdd1e24ba=
%40isocpp.org</a>.<br />
------=_Part_80_1263958689.1493238222894--
------=_Part_79_2068456158.1493238222894--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 26 Apr 2017 13:28:45 -0700
Raw View
On Wed, Apr 26, 2017 at 1:23 PM, 'Thomas K=C3=B6ppe' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> A random thought - how about:
>
> template <auto V> struct c : std::integral_constant<decltype(V), V> {=
};
>
> Usage:
>
> func(c(10)); // calls func(std::integral_constant<int, 10>)
>
> (This may require a deduction guide, I'm not sure.)
std::integral_constant has no constructor taking
`10` so this doesn't work.
--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
--=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/CAGsORuB08uPs%2Bsqrc40BQsWACKNAcdynqMXaVhmHEAR77=
TatmQ%40mail.gmail.com.
.
Author: =?UTF-8?Q?=27Thomas_K=C3=B6ppe=27_via_ISO_C=2B=2B_Standard_=2D_Future_Proposals?= <std-proposals@isocpp.org>
Date: Wed, 26 Apr 2017 13:45:30 -0700 (PDT)
Raw View
------=_Part_396_1182988840.1493239530652
Content-Type: multipart/alternative;
boundary="----=_Part_397_100385158.1493239530652"
------=_Part_397_100385158.1493239530652
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, 26 April 2017 21:23:43 UTC+1, Thomas K=C3=B6ppe wrote:
>
> A random thought - how about:
>
> template <auto V> struct c : std::integral_constant<decltype(V), V> {=
};
>
> Usage:
>
> func(c(10)); // calls func(std::integral_constant<int, 10>)
>
> (This may require a deduction guide, I'm not sure.)
>
No, never mind, that doesn't make any sense at all. You could write=20
func(c<10>()) I suppose (no deduction guides required), but it's a bit of a=
=20
hack.=20
--=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/9c54b81f-28c3-4659-9022-e71f5d05da7a%40isocpp.or=
g.
------=_Part_397_100385158.1493239530652
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Wednesday, 26 April 2017 21:23:43 UTC+1, Thomas K=
=C3=B6ppe wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">A random thought - how about:<div><br></div><div>=C2=A0 =C2=A0 template=
<auto V> struct c : std::integral_constant<<wbr>decltype(V), V>=
; {};</div><div><br></div><div>Usage:</div><div><br></div><div>=C2=A0 =C2=
=A0 func(c(10)); =C2=A0// calls func(std::integral_constant<<wbr>int, 10=
>)</div><div><br></div><div>(This may require a deduction guide, I'm=
not sure.)</div></div></blockquote><div><br></div><div>No, never mind, tha=
t doesn't make any sense at all. You could write func(c<10>()) I =
suppose (no deduction guides required), but it's a bit of a hack.=C2=A0=
</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/9c54b81f-28c3-4659-9022-e71f5d05da7a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9c54b81f-28c3-4659-9022-e71f5d05da7a=
%40isocpp.org</a>.<br />
------=_Part_397_100385158.1493239530652--
------=_Part_396_1182988840.1493239530652--
.
Author: Zach Laine <whatwasthataddress@gmail.com>
Date: Wed, 26 Apr 2017 15:53:20 -0500
Raw View
--001a114fde9ccedde3054e180799
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The way Boost.Hana handles this is with a UDL for its own integral constant
type. So getting the Nth value of a tuple might look like this:
hana::tuple</*...*/> t;
auto second_element =3D t[1_c];
The tuple's operator[] can therefore be evaluated at compile time
(depending on the element types of course).
It might be nice to have something similar for std::integral_constant<T>,
though the possibility of several different valid instantiations makes this
nontrivial.
Zach
On Wed, Apr 26, 2017 at 3:45 PM, 'Thomas K=C3=B6ppe' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> On Wednesday, 26 April 2017 21:23:43 UTC+1, Thomas K=C3=B6ppe wrote:
>>
>> A random thought - how about:
>>
>> template <auto V> struct c : std::integral_constant<decltype(V), V>
>> {};
>>
>> Usage:
>>
>> func(c(10)); // calls func(std::integral_constant<int, 10>)
>>
>> (This may require a deduction guide, I'm not sure.)
>>
>
> No, never mind, that doesn't make any sense at all. You could write
> func(c<10>()) I suppose (no deduction guides required), but it's a bit of=
a
> hack.
>
> --
> 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/9c54b81f-28c3-4659-
> 9022-e71f5d05da7a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9c54b81f-28=
c3-4659-9022-e71f5d05da7a%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/CALOpkJAvsX_EYkkvDUGA50FnK8dDay8S5fqyRU8AiL%3D91=
1neAQ%40mail.gmail.com.
--001a114fde9ccedde3054e180799
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The way Boost.Hana handles this is with a UDL for its own =
integral constant type.=C2=A0 So getting the Nth value of a tuple might loo=
k like this:<div><br></div><div>hana::tuple</*...*/> t;</div><div>aut=
o second_element =3D t[1_c];<br></div><div><br></div><div>The tuple's o=
perator[] can therefore be evaluated at compile time (depending on the elem=
ent types of course).</div><div><br></div><div>It might be nice to have som=
ething similar for std::integral_constant<T>, though the possibility =
of several different valid instantiations makes this nontrivial.</div><div>=
<br></div><div>Zach</div><div><br></div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Wed, Apr 26, 2017 at 3:45 PM, 'Thomas K=
=C3=B6ppe' via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&l=
t;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposa=
ls@isocpp.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><span class=3D""><br>On Wednesday, 26 April 2017 21:23:43 UTC+1=
, Thomas K=C3=B6ppe wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">A random thought - how about:<div><br></div><div>=C2=A0 =C2=A0 tem=
plate <auto V> struct c : std::integral_constant<decltyp<wbr>e(V),=
V> {};</div><div><br></div><div>Usage:</div><div><br></div><div>=C2=A0 =
=C2=A0 func(c(10)); =C2=A0// calls func(std::integral_constant<in<wbr>t,=
10>)</div><div><br></div><div>(This may require a deduction guide, I=
9;m not sure.)</div></div></blockquote><div><br></div></span><div>No, never=
mind, that doesn't make any sense at all. You could write func(c<10=
>()) I suppose (no deduction guides required), but it's a bit of a h=
ack.=C2=A0</div></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/9c54b81f-28c3-4659-9022-e71f5d05da7a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/9c54=
b81f-28c3-4659-<wbr>9022-e71f5d05da7a%40isocpp.org</a><wbr>.<br>
</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/CALOpkJAvsX_EYkkvDUGA50FnK8dDay8S5fqy=
RU8AiL%3D911neAQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALOpkJAvsX_EYk=
kvDUGA50FnK8dDay8S5fqyRU8AiL%3D911neAQ%40mail.gmail.com</a>.<br />
--001a114fde9ccedde3054e180799--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 26 Apr 2017 14:01:29 -0700
Raw View
On Wed, Apr 26, 2017 at 12:29 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> template<size_t N>
> constexpr auto func(std::integral_constant_t<size_t, N>)
> {
> return std::array<int, N>{};
> }
>
> The problem with this is that you have to invoke such a function in a very
> unnatural way: `func(std::integral_constant<std::size_t, 20>);` That puts a
> lot of noise in the function argument, when what you really want to say is
> `func(20);`
>
> What I suggest is making `integral_constant` specially recognized by the
> compiler in template argument deduction circumstances.
I have the same thought. I also want valued-type to just
work as well:
template <typename T>
struct type {}; // hana::type
template <typename T>
void f(type<T> x, ...);
f(int); // picked up by overload resolution
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
--
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/CAGsORuC6cdx_J6pr_BnNKq7JXCA0Sp-n2P6zb1yHErRda17j2w%40mail.gmail.com.
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Wed, 26 Apr 2017 18:08:12 -0300
Raw View
Hi,
2017-04-26 16:29 GMT-03:00 Nicol Bolas <jmckesson@gmail.com>:
> Function parameters in `constexpr` functions aren't constexpr; only non-type
> template parameters are considered constant expressions. However, you can
> approximate `constexpr` parameters through the use of a type:
>
> template<size_t N>
> constexpr auto func(std::integral_constant_t<size_t, N>)
> {
> return std::array<int, N>{};
> }
>
> The problem with this is that you have to invoke such a function in a very
> unnatural way: `func(std::integral_constant<std::size_t, 20>);` That puts a
> lot of noise in the function argument, when what you really want to say is
> `func(20);`
>
> What I suggest is making `integral_constant` specially recognized by the
> compiler in template argument deduction circumstances. If the given argument
> for such a parameter is either an integer literal (with a non-narrowing
> conversion to the `integral_constant`'s type) or a constexpr variable (who's
> type has a non-narrowing conversion to the `integral_constant`'s type), then
> the compiler will deduce the corresponding `N` as if you had spelled out
> `std::integral_constant_t<typename>`. If the type of `integral_constant` is
> also deduced (either via C++17's `auto` or as a template parameter), then
> this would work as well, simply using the type of the expression.
>
> We could also add more `type_constant` types to the standard library, like
> `float_constant`, `pointer_constant`, etc.
>
> One reason I bring this up is that this feels like it's really a part of a
> more generic feature, but I can't think of what such a feature might look
> like. This looks like some mechanism for customizing how template argument
> deduction works, but what would that actually be?
FYI, some interesting discussion on a related topic:
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/constexpr$20function$20arguments/std-proposals/6qGR67u-Z9I/3QWtwZYBWasJ
Marcelo
--
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/CAPGXEnETnEviHDcc4i5aFJpV%2B3zahyJQfinLRbQXqYHr%3Dqiz9g%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 26 Apr 2017 17:23:36 -0700 (PDT)
Raw View
------=_Part_5263_1290662081.1493252616236
Content-Type: multipart/alternative;
boundary="----=_Part_5264_1084368342.1493252616237"
------=_Part_5264_1084368342.1493252616237
Content-Type: text/plain; charset=UTF-8
On Wednesday, April 26, 2017 at 4:17:15 PM UTC-4, John McFarlane wrote:
>
> I would also like to be able to do more static work with function
> parameters. For example:
>
> auto x = just_wide_enough(100); // returns an int8_t
> auto y = just_wide_enough(1000); // returns an int16_t
>
> Note that it is already possible to generate integral_constant from
> user-defined literals so `func(20_c)` is a workaround, e.g. [
> http://www.boost.org/doc/libs/1_61_0/libs/hana/doc/html/namespaceboost_1_1hana_1_1literals.html#a85ac3c47d02722a334181aab540e732c
> ].
>
>
That's a partial solution. It doesn't allow `constexpr` variables to be
used. Nor can it handle narrowing conversions properly.
--
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/099bb4a7-5a3e-4f02-bfed-1ac7e032641d%40isocpp.org.
------=_Part_5264_1084368342.1493252616237
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, April 26, 2017 at 4:17:15 PM UTC-4, =
John McFarlane 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"><div><div><div>I would also like to be able to do more static work=
with function parameters. For example:<br><br></div>auto x =3D just_wide_e=
nough(100);=C2=A0 // returns an int8_t<br></div>auto y =3D just_wide_enough=
(1000);=C2=A0 // returns an int16_t<br><br></div>Note that it is already po=
ssible to generate integral_constant from user-defined literals so `func(20=
_c)` is a workaround, e.g. [<a href=3D"http://www.boost.org/doc/libs/1_61_0=
/libs/hana/doc/html/namespaceboost_1_1hana_1_1literals.html#a85ac3c47d02722=
a334181aab540e732c" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.boost.org%2Fdoc=
%2Flibs%2F1_61_0%2Flibs%2Fhana%2Fdoc%2Fhtml%2Fnamespaceboost_1_1hana_1_1lit=
erals.html%23a85ac3c47d02722a334181aab540e732c\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNH-7g4S07yfdYHQj-60nWipbY3aeg';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.boost.org%2Fdo=
c%2Flibs%2F1_61_0%2Flibs%2Fhana%2Fdoc%2Fhtml%2Fnamespaceboost_1_1hana_1_1li=
terals.html%23a85ac3c47d02722a334181aab540e732c\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNH-7g4S07yfdYHQj-60nWipbY3aeg';return true;">http://www.boo=
st.org/doc/<wbr>libs/1_61_0/libs/hana/doc/<wbr>html/namespaceboost_1_1hana_=
1_<wbr>1literals.html#<wbr>a85ac3c47d02722a334181aab540e7<wbr>32c</a>].</di=
v><br></blockquote><div><br>That's a partial solution. It doesn't a=
llow `constexpr` variables to be used. Nor can it handle narrowing conversi=
ons properly.<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/099bb4a7-5a3e-4f02-bfed-1ac7e032641d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/099bb4a7-5a3e-4f02-bfed-1ac7e032641d=
%40isocpp.org</a>.<br />
------=_Part_5264_1084368342.1493252616237--
------=_Part_5263_1290662081.1493252616236--
.
Author: Chris DeVisser <chris.n.devisser@gmail.com>
Date: Thu, 27 Apr 2017 06:09:02 -0700 (PDT)
Raw View
------=_Part_4214_19097568.1493298542173
Content-Type: multipart/alternative;
boundary="----=_Part_4215_1975976045.1493298542173"
------=_Part_4215_1975976045.1493298542173
Content-Type: text/plain; charset=UTF-8
On Wednesday, April 26, 2017 at 3:29:33 PM UTC-4, Nicol Bolas wrote:
>
> Function parameters in `constexpr` functions aren't constexpr; only
> non-type template parameters are considered constant expressions. However,
> you can approximate `constexpr` parameters through the use of a type:
>
> template<size_t N>
> constexpr auto func(std::integral_constant_t<size_t, N>)
> {
> return std::array<int, N>{};
> }
>
> The problem with this is that you have to invoke such a function in a very
> unnatural way: `func(std::integral_constant<std::size_t, 20>);` That puts a
> lot of noise in the function argument, when what you really want to say is
> `func(20);`
>
> What I suggest is making `integral_constant` specially recognized by the
> compiler in template argument deduction circumstances. If the given
> argument for such a parameter is either an integer literal (with a
> non-narrowing conversion to the `integral_constant`'s type) or a constexpr
> variable (who's type has a non-narrowing conversion to the
> `integral_constant`'s type), then the compiler will deduce the
> corresponding `N` as if you had spelled out
> `std::integral_constant_t<typename>`. If the type of `integral_constant` is
> also deduced (either via C++17's `auto` or as a template parameter), then
> this would work as well, simply using the type of the expression.
>
> We could also add more `type_constant` types to the standard library, like
> `float_constant`, `pointer_constant`, etc.
>
> One reason I bring this up is that this feels like it's really a part of a
> more generic feature, but I can't think of what such a feature might look
> like. This looks like some mechanism for customizing how template argument
> deduction works, but what would that actually be?
>
FWIW, @ubsan in the C++ Slack came up with something similar to allow any
constexpr-enabled type to be used in this way, using the same technique as
Hana's string does, but generalized: https://godbolt.org/g/U6KjKf
In particular:
#define typeval(_value) []() {\
struct __anonymous {\
using type = decltype(_value);\
constexpr static auto value() -> type {\
return _value;\
}\
};\
return __anonymous();\
}()
This allows, for example, foo(typeval(2.5)) to have a compile-time-only
double parameter. While the if constexpr() proposal is great for
all-or-nothing, it doesn't easily support having, say, a compile-time
format string and compile-time or runtime value arguments. Perhaps this
approach is worth exploring? The question becomes how best to avoid the
need for using typeval at the call site and how to make it friendly for the
function author to use in the first place.
I'm also interested to see what ideas SG7 has about compile-time-only
parameters in general.
--
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/8234512e-3c3d-457a-a269-01e6e197cc8d%40isocpp.org.
------=_Part_4215_1975976045.1493298542173
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, April 26, 2017 at 3:29:33 PM UTC-4, =
Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Function parameters in `constexpr` functions aren't constexpr; onl=
y non-type template parameters are considered constant expressions. However=
, you can approximate `constexpr` parameters through the use of a type:<br>=
<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px"><code><div><span style=3D"color=
:#008">template</span><span style=3D"color:#660"><</span><span style=3D"=
color:#000">size_t N</span><span style=3D"color:#660">></span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#008">constexpr</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">auto</span><span =
style=3D"color:#000"> func</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#000">std</span><span style=3D"color:#660">::</span><span sty=
le=3D"color:#000">integral_constant_t</span><span style=3D"color:#660"><=
</span><span style=3D"color:#000"><wbr>size_t</span><span style=3D"color:#6=
60">,</span><span style=3D"color:#000"> N</span><span style=3D"color:#660">=
>)</span><span style=3D"color:#000"><br></span><span style=3D"color:#660=
">{</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color=
:#008">return</span><span style=3D"color:#000"> std</span><span style=3D"co=
lor:#660">::</span><span style=3D"color:#000">array</span><span style=3D"co=
lor:#660"><</span><span style=3D"color:#008">int</span><span style=3D"co=
lor:#660">,</span><span style=3D"color:#000"> N</span><span style=3D"color:=
#660">>{};</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#660">}</span></div></code></div><br>The problem with this is that you =
have to invoke such a function in a very unnatural way: `func(std::integral=
_constant<<wbr>std::size_t, 20>);` That puts a lot of noise in the fu=
nction argument, when what you really want to say is `func(20);`</div></blo=
ckquote><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>W=
hat I suggest is making `integral_constant` specially recognized by the com=
piler in template argument deduction circumstances. If the given argument f=
or such a parameter is either an integer literal (with a non-narrowing conv=
ersion to the `integral_constant`'s type) or a constexpr variable (who&=
#39;s type has a non-narrowing conversion to the `integral_constant`'s =
type), then the compiler will deduce the corresponding `N` as if you had sp=
elled out `std::integral_constant_t<<wbr>typename>`. If the type of `=
integral_constant` is also deduced (either via C++17's `auto` or as a t=
emplate parameter), then this would work as well, simply using the type of =
the expression.<br><br>We could also add more `type_constant` types to the =
standard library, like `float_constant`, `pointer_constant`, etc.=C2=A0</di=
v></blockquote><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>One reason I bring this up is that this feels like it's really a =
part of a more generic feature, but I can't think of what such a featur=
e might look like. This looks like some mechanism for customizing how templ=
ate argument deduction works, but what would that actually be?<br></div></b=
lockquote><div><br></div><div><div style=3D"font-family: arial, sans-serif;=
font-size: small;"><br class=3D"Apple-interchange-newline">FWIW, @ubsan in=
the C++ Slack came up with something similar to allow any constexpr-enable=
d type to be used in this way, using the same technique as Hana's strin=
g does, but generalized:=C2=A0<a href=3D"https://godbolt.org/g/U6KjKf">http=
s://godbolt.org/g/U6KjKf</a></div><div style=3D"font-family: arial, sans-se=
rif; font-size: small;"><br></div><div style=3D"font-family: arial, sans-se=
rif; font-size: small;">In particular:</div><div style=3D"font-family: aria=
l, sans-serif; font-size: small;"><br></div><div style=3D"font-family: aria=
l, sans-serif; font-size: small;"><div class=3D"prettyprint" style=3D"borde=
r-width: 1px; border-style: solid; border-color: rgb(187, 187, 187); backgr=
ound-color: rgb(250, 250, 250); word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=
=3D"styled-by-prettify">#define</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> typeval</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">_value</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]()</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{\</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> __anonymous </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{\</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">using</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> type </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 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">_value</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
);\</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>constexpr</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">static</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> value</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">-></span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> type </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{\</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> _value</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;\</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">}\</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">};\</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
__anonymous</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>=
</div></code></div><div><br></div></div></div><div>This allows, for example=
,=C2=A0<font face=3D"courier new, monospace">foo(typeval(2.5))</font>=C2=A0=
to have a compile-time-only=C2=A0<font face=3D"courier new, monospace">doub=
le</font>=C2=A0parameter. While the=C2=A0<font face=3D"courier new, monospa=
ce">if=C2=A0constexpr()</font>=C2=A0proposal is great for all-or-nothing, i=
t doesn't easily support having, say, a compile-time format string and =
compile-time or runtime value arguments. Perhaps this approach is worth exp=
loring? The question becomes how best to avoid the need for using <font fac=
e=3D"courier new, monospace">typeval</font> at the call site and=C2=A0how t=
o make it friendly for the function author to use in the first place.</div>=
<div><br></div><div>I'm also interested to see what ideas SG7 has about=
compile-time-only parameters in general.</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/8234512e-3c3d-457a-a269-01e6e197cc8d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8234512e-3c3d-457a-a269-01e6e197cc8d=
%40isocpp.org</a>.<br />
------=_Part_4215_1975976045.1493298542173--
------=_Part_4214_19097568.1493298542173--
.
Author: Louis Dionne <ldionne.2@gmail.com>
Date: Thu, 27 Apr 2017 07:52:31 -0700 (PDT)
Raw View
------=_Part_4076_251920785.1493304751219
Content-Type: multipart/alternative;
boundary="----=_Part_4077_2105641454.1493304751220"
------=_Part_4077_2105641454.1493304751220
Content-Type: text/plain; charset=UTF-8
Just for historical accuracy, I believe the technique Chris mentions was
first introduced by Michael Park in 2014 in his `format`
library: https://github.com/mpark/format. I remember talking to him about
this at CppCon that year and then deriving Hana's `BOOST_HANA_STRING` macro
(for compile-time strings) from it.
As for the general feature, I believe solving this problem is equivalent to
allow passing arbitrary constexpr types as non-type template parameters.
Indeed, given such a feature, we could simply say that a `constexpr`
parameter is equivalent to passing it as a non-type template parameter,
with syntactic sugar. However, implementing this is highly non-trivial, as
it requires the ability to determine when two non-type template arguments
are "equal", which could be very involved for user-defined types. Of
course, a partial solution that allows only a subset of user defined types
might also be enough.
Louis
On Thursday, 27 April 2017 14:09:02 UTC+1, Chris DeVisser wrote:
>
>
>
> On Wednesday, April 26, 2017 at 3:29:33 PM UTC-4, Nicol Bolas wrote:
>>
>> Function parameters in `constexpr` functions aren't constexpr; only
>> non-type template parameters are considered constant expressions. However,
>> you can approximate `constexpr` parameters through the use of a type:
>>
>> template<size_t N>
>> constexpr auto func(std::integral_constant_t<size_t, N>)
>> {
>> return std::array<int, N>{};
>> }
>>
>> The problem with this is that you have to invoke such a function in a
>> very unnatural way: `func(std::integral_constant<std::size_t, 20>);` That
>> puts a lot of noise in the function argument, when what you really want to
>> say is `func(20);`
>>
>
>> What I suggest is making `integral_constant` specially recognized by the
>> compiler in template argument deduction circumstances. If the given
>> argument for such a parameter is either an integer literal (with a
>> non-narrowing conversion to the `integral_constant`'s type) or a constexpr
>> variable (who's type has a non-narrowing conversion to the
>> `integral_constant`'s type), then the compiler will deduce the
>> corresponding `N` as if you had spelled out
>> `std::integral_constant_t<typename>`. If the type of `integral_constant` is
>> also deduced (either via C++17's `auto` or as a template parameter), then
>> this would work as well, simply using the type of the expression.
>>
>> We could also add more `type_constant` types to the standard library,
>> like `float_constant`, `pointer_constant`, etc.
>>
>
>> One reason I bring this up is that this feels like it's really a part of
>> a more generic feature, but I can't think of what such a feature might look
>> like. This looks like some mechanism for customizing how template argument
>> deduction works, but what would that actually be?
>>
>
>
> FWIW, @ubsan in the C++ Slack came up with something similar to allow any
> constexpr-enabled type to be used in this way, using the same technique as
> Hana's string does, but generalized: https://godbolt.org/g/U6KjKf
>
> In particular:
>
> #define typeval(_value) []() {\
> struct __anonymous {\
> using type = decltype(_value);\
> constexpr static auto value() -> type {\
> return _value;\
> }\
> };\
> return __anonymous();\
> }()
>
> This allows, for example, foo(typeval(2.5)) to have a compile-time-only
> double parameter. While the if constexpr() proposal is great for
> all-or-nothing, it doesn't easily support having, say, a compile-time
> format string and compile-time or runtime value arguments. Perhaps this
> approach is worth exploring? The question becomes how best to avoid the
> need for using typeval at the call site and how to make it friendly for
> the function author to use in the first place.
>
> I'm also interested to see what ideas SG7 has about compile-time-only
> parameters in general.
>
--
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/1dbc47da-63af-4274-8a2f-785343efb89f%40isocpp.org.
------=_Part_4077_2105641454.1493304751220
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Just for historical accuracy, I believe the technique=
Chris mentions was first introduced by Michael Park in 2014 in his `format=
` library:=C2=A0https://github.com/mpark/format. I remember talking to him =
about this at CppCon that year and then deriving Hana's `BOOST_HANA_STR=
ING` macro (for compile-time strings) from it.</div><div><br></div><div>As =
for the general feature, I believe solving this problem is equivalent to al=
low passing arbitrary constexpr types as non-type template parameters. Inde=
ed, given such a feature, we could simply say that a `constexpr` parameter =
is equivalent to passing it as a non-type template parameter, with syntacti=
c sugar. However, implementing this is highly non-trivial, as it requires t=
he ability to determine when two non-type template arguments are "equa=
l", which could be very involved for user-defined types. Of course, a =
partial solution that allows only a subset of user defined types might also=
be enough.</div><div><br></div><div>Louis</div><br>On Thursday, 27 April 2=
017 14:09:02 UTC+1, Chris DeVisser 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><br>On Wednesday, April 26, 2017 at 3:29:3=
3 PM UTC-4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">Function parameters in `constexpr` functions aren't constex=
pr; only non-type template parameters are considered constant expressions. =
However, you can approximate `constexpr` parameters through the use of a ty=
pe:<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:#008">template</span><span style=3D"color:#660"><</span><span =
style=3D"color:#000">size_t N</span><span style=3D"color:#660">></span><=
span style=3D"color:#000"><br></span><span style=3D"color:#008">constexpr</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">auto</sp=
an><span style=3D"color:#000"> func</span><span style=3D"color:#660">(</spa=
n><span style=3D"color:#000">std</span><span style=3D"color:#660">::</span>=
<span style=3D"color:#000">integral_constant_t</span><span style=3D"color:#=
660"><</span><span style=3D"color:#000"><wbr>size_t</span><span style=3D=
"color:#660">,</span><span style=3D"color:#000"> N</span><span style=3D"col=
or:#660">>)</span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=
=3D"color:#008">return</span><span style=3D"color:#000"> std</span><span st=
yle=3D"color:#660">::</span><span style=3D"color:#000">array</span><span st=
yle=3D"color:#660"><</span><span style=3D"color:#008">int</span><span st=
yle=3D"color:#660">,</span><span style=3D"color:#000"> N</span><span style=
=3D"color:#660">>{};</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#660">}</span></div></code></div><br>The problem with this is=
that you have to invoke such a function in a very unnatural way: `func(std=
::integral_constant<<wbr>std::size_t, 20>);` That puts a lot of noise=
in the function argument, when what you really want to say is `func(20);`<=
/div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<br>What I suggest is making `integral_constant` specially recognized by th=
e compiler in template argument deduction circumstances. If the given argum=
ent for such a parameter is either an integer literal (with a non-narrowing=
conversion to the `integral_constant`'s type) or a constexpr variable =
(who's type has a non-narrowing conversion to the `integral_constant`&#=
39;s type), then the compiler will deduce the corresponding `N` as if you h=
ad spelled out `std::integral_constant_t<<wbr>typename>`. If the type=
of `integral_constant` is also deduced (either via C++17's `auto` or a=
s a template parameter), then this would work as well, simply using the typ=
e of the expression.<br><br>We could also add more `type_constant` types to=
the standard library, like `float_constant`, `pointer_constant`, etc.=C2=
=A0</div></blockquote><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"l=
tr"><br>One reason I bring this up is that this feels like it's really =
a part of a more generic feature, but I can't think of what such a feat=
ure might look like. This looks like some mechanism for customizing how tem=
plate argument deduction works, but what would that actually be?<br></div><=
/blockquote><div><br></div><div><div style=3D"font-family:arial,sans-serif;=
font-size:small"><br>FWIW, @ubsan in the C++ Slack came up with something s=
imilar to allow any constexpr-enabled type to be used in this way, using th=
e same technique as Hana's string does, but generalized:=C2=A0<a href=
=3D"https://godbolt.org/g/U6KjKf" target=3D"_blank" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgod=
bolt.org%2Fg%2FU6KjKf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG1ziUTw9p3XDj=
ouz0NtPE_4WRaQQ';return true;" onclick=3D"this.href=3D'https://www.=
google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FU6KjKf\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNG1ziUTw9p3XDjouz0NtPE_4WRaQQ';return true;">htt=
ps://godbolt.<wbr>org/g/U6KjKf</a></div><div style=3D"font-family:arial,san=
s-serif;font-size:small"><br></div><div style=3D"font-family:arial,sans-ser=
if;font-size:small">In particular:</div><div style=3D"font-family:arial,san=
s-serif;font-size:small"><br></div><div style=3D"font-family:arial,sans-ser=
if;font-size:small"><div style=3D"border-width:1px;border-style:solid;borde=
r-color:rgb(187,187,187);background-color:rgb(250,250,250);word-wrap:break-=
word"><code><div><span style=3D"color:#800">#define</span><span style=3D"co=
lor:#000"> typeval</span><span style=3D"color:#660">(</span><span style=3D"=
color:#000">_value</span><span style=3D"color:#660">)</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">[]()</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">{\</span><span style=3D"color:=
#000"><br>=C2=A0 </span><span style=3D"color:#008">struct</span><span style=
=3D"color:#000"> __anonymous </span><span style=3D"color:#660">{\</span><sp=
an style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008"=
>using</span><span style=3D"color:#000"> type </span><span style=3D"color:#=
660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#008=
">decltype</span><span style=3D"color:#660">(</span><span style=3D"color:#0=
00">_value</span><span style=3D"color:#660">);\</span><span style=3D"color:=
#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">constexpr</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">static</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">auto</span><sp=
an style=3D"color:#000"> value</span><span style=3D"color:#660">()</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">-></span><sp=
an style=3D"color:#000"> type </span><span style=3D"color:#660">{\</span><s=
pan style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"col=
or:#008">return</span><span style=3D"color:#000"> _value</span><span style=
=3D"color:#660">;\</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </spa=
n><span style=3D"color:#660">}\</span><span style=3D"color:#000"><br>=C2=A0=
</span><span style=3D"color:#660">};\</span><span style=3D"color:#000"><br=
>=C2=A0 </span><span style=3D"color:#008">return</span><span style=3D"color=
:#000"> __anonymous</span><span style=3D"color:#660">();\</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">}()</span></div></cod=
e></div><div><br></div></div></div><div>This allows, for example,=C2=A0<fon=
t face=3D"courier new, monospace">foo(typeval(2.5))</font>=C2=A0to have a c=
ompile-time-only=C2=A0<font face=3D"courier new, monospace">double</font>=
=C2=A0<wbr>parameter. While the=C2=A0<font face=3D"courier new, monospace">=
if=C2=A0constexpr()</font>=C2=A0proposal is great for all-or-nothing, it do=
esn't easily support having, say, a compile-time format string and comp=
ile-time or runtime value arguments. Perhaps this approach is worth explori=
ng? The question becomes how best to avoid the need for using <font face=3D=
"courier new, monospace">typeval</font> at the call site and=C2=A0how to ma=
ke it friendly for the function author to use in the first place.</div><div=
><br></div><div>I'm also interested to see what ideas SG7 has about com=
pile-time-only parameters in general.</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/1dbc47da-63af-4274-8a2f-785343efb89f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1dbc47da-63af-4274-8a2f-785343efb89f=
%40isocpp.org</a>.<br />
------=_Part_4077_2105641454.1493304751220--
------=_Part_4076_251920785.1493304751219--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Thu, 27 Apr 2017 14:15:15 -0700 (PDT)
Raw View
------=_Part_56_1563920375.1493327715560
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, 26 April 2017 21:45:30 UTC+1, Thomas K=C3=B6ppe wrote:
> On Wednesday, 26 April 2017 21:23:43 UTC+1, Thomas K=C3=B6ppe wrote:
> A random thought - how about:
>=20
>=20
> =C2=A0 =C2=A0 template <auto V> struct c : std::integral_constant<decltyp=
e(V), V> {};
>=20
>=20
> Usage:
>=20
>=20
> =C2=A0 =C2=A0 func(c(10)); =C2=A0// calls func(std::integral_constant<int=
, 10>)
>=20
>=20
> (This may require a deduction guide, I'm not sure.)
>=20
>=20
> No, never mind, that doesn't make any sense at all. You could write func(=
c<10>()) I suppose (no deduction guides required), but it's a bit of a hack=
..=C2=A0
However with variable templates we can write:
template<auto I> auto const_v =3D
std::integral_constant<decltype(I), I>{};
func(const_v<20u>);
I've started using this technique quite a lot in metaprogramming recently.=
=20
--=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/7724e437-c984-48ff-a757-8e542a813cef%40isocpp.or=
g.
------=_Part_56_1563920375.1493327715560--
.