------=_Part_1698_150667300.1498499265123
Content-Type: multipart/alternative;
 boundary="----=_Part_1699_1024560599.1498499265123"

------=_Part_1699_1024560599.1498499265123
Content-Type: text/plain; charset="UTF-8"

Over the last few years, we've had this large proliferation of constexpr functions
- especially after C++14 relaxed what was allowed to be constexpr. Now
we're in this state where basically any type that is literal just has all
of its member functions marked constexpr. This ends up being really...
weird. std::string_view for instance has member functions like:

constexpr void remove_prefix(size_type );
constexpr void swap(basic_string_view& ) noexcept;

These seem fundamentally... odd. constexpr looks a lot like const so my
first reaction is always "well, how can you possibly swap constexpr? How
does constexpr void make sense?" But then, constexpr is there because it
has to be to used in a constexpr function. It doesn't *really* provide any
meaning. It doesn't change what the function does or how it works, it's
just a toggle that makes it suddenly allowed. We just end up with this constexpr
creep where we just have to annotate all the things... Because... reasons.

In a C++17 world, what are those reasons actually? Should we just have constexpr
by default? Can we?

--
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/1216e17a-8440-43b2-b24f-96a40f25ec17%40isocpp.org.

------=_Part_1699_1024560599.1498499265123
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Over the last few years, we&#39;ve had this large prolifer=
ation of <font face=3D"courier new, monospace">constexpr </font>functions -=
 especially after C++14 relaxed what was allowed to be <font face=3D"courie=
r new, monospace">constexpr</font>. Now we&#39;re in this state where basic=
ally any type that is literal just has all of its member functions marked <=
font face=3D"courier new, monospace">constexpr</font>. This ends up being r=
eally... weird. <font face=3D"courier new, monospace">std::string_view</fon=
t> for instance has member functions like:<div><br></div><div><div class=3D=
"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: =
rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: brea=
k-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><font co=
lor=3D"#660066"><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
onstexpr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> remove_prefix</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">size_type </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"co=
lor: #008;" class=3D"styled-by-prettify">constexpr</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> swap</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">basic_string_view</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> noex=
cept</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></fo=
nt></div></code></div><br>These seem fundamentally... odd. <font face=3D"co=
urier new, monospace">constexpr </font>looks a lot like const so my first r=
eaction is always &quot;well, how can you possibly swap constexpr? How does=
 constexpr void make sense?&quot; But then, <font face=3D"courier new, mono=
space">constexpr </font>is there because it has to be to used in a <font fa=
ce=3D"courier new, monospace">constexpr </font>function. It doesn&#39;t <i>=
really</i>=C2=A0provide any meaning. It doesn&#39;t change what the functio=
n does or how it works, it&#39;s just a toggle that makes it suddenly allow=
ed. We just end up with this <font face=3D"courier new, monospace">constexp=
r </font>creep where we just have to annotate all the things... Because... =
reasons.=C2=A0</div><div><br></div><div>In a C++17 world, what are those re=
asons actually? Should we just have <font face=3D"courier new, monospace">c=
onstexpr </font>by default? Can we?=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&quot; 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/1216e17a-8440-43b2-b24f-96a40f25ec17%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1216e17a-8440-43b2-b24f-96a40f25ec17=
%40isocpp.org</a>.<br />

------=_Part_1699_1024560599.1498499265123--

------=_Part_1698_150667300.1498499265123--

.

2017-06-26 19:47 GMT+02:00 Barry Revzin <barry.revzin@gmail.com>:
> Over the last few years, we've had this large proliferation of constexpr
> functions - especially after C++14 relaxed what was allowed to be constexpr.
> Now we're in this state where basically any type that is literal just has
> all of its member functions marked constexpr. This ends up being really...
> weird. std::string_view for instance has member functions like:
>
> constexpr void remove_prefix(size_type );
> constexpr void swap(basic_string_view& ) noexcept;
>
> These seem fundamentally... odd. constexpr looks a lot like const so my
> first reaction is always "well, how can you possibly swap constexpr? How
> does constexpr void make sense?" But then, constexpr is there because it has
> to be to used in a constexpr function. It doesn't really provide any
> meaning. It doesn't change what the function does or how it works, it's just
> a toggle that makes it suddenly allowed. We just end up with this constexpr
> creep where we just have to annotate all the things... Because... reasons.
>
> In a C++17 world, what are those reasons actually? Should we just have
> constexpr by default? Can we?

Two thoughts:

1) How do I opt out, if it becomes the default?
2) What about constexpr as constant initialization constructor?

Thanks,

- Daniel

--
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/CAGNvRgDsVdiymp_%3DjuLpJxuso2end4irYRFBbH5VzKXhxwJRjg%40mail.gmail.com.

.

On 26.06.2017 19:52, Daniel Kr=C3=BCgler wrote:
> Two thoughts:
>=20
> 1) How do I opt out, if it becomes the default?

Why would you want to opt out?

Just write a function as normal. If it can be constexpr, good. Otherwise=20
it won't be constexpr.

> 2) What about constexpr as constant initialization constructor?

You mean on variables?
Constructor can be auto constexpr as well.

--=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/f7beae19-d36c-4451-761a-33ae767badd7%40gmail.com=
..

.

2017-06-26 20:19 GMT+02:00 Jonathan M=C3=BCller <jonathanmueller.dev@gmail.=
com>:
> On 26.06.2017 19:52, Daniel Kr=C3=BCgler wrote:
>>
>> Two thoughts:
>>
>> 1) How do I opt out, if it becomes the default?
>
>
> Why would you want to opt out?
>
> Just write a function as normal. If it can be constexpr, good. Otherwise =
it
> won't be constexpr.

That is not sufficient, because according to the current situation a
program can be ill-formed, if a function is marked as constexpr and
some other condition applies. This applies to main() but also to
[dcl.constexpr] p5, just as examples. What I'm trying to say here is:
This is not just as simple as "Just let's make it the default".

-Daniel

--=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/CAGNvRgAB1W7954%2B%2B4sJ1FWN_CPgi4aJrSKPSnEomUFZ=
az2B0GA%40mail.gmail.com.

.

--001a113ddafc2494ea0552e133ed
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2017-06-26 20:26 GMT+02:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com>:

> 2017-06-26 20:19 GMT+02:00 Jonathan M=C3=BCller <jonathanmueller.dev@gmai=
l.com
> >:
> > On 26.06.2017 19:52, Daniel Kr=C3=BCgler wrote:
> >>
> >> Two thoughts:
> >>
> >> 1) How do I opt out, if it becomes the default?
> >
> >
> > Why would you want to opt out?
> >
> > Just write a function as normal. If it can be constexpr, good. Otherwis=
e
> it
> > won't be constexpr.
>
> That is not sufficient, because according to the current situation a
> program can be ill-formed, if a function is marked as constexpr and
> some other condition applies. This applies to main() but also to
> [dcl.constexpr] p5, just as examples. What I'm trying to say here is:
> This is not just as simple as "Just let's make it the default".
>
> -Daniel
>
> --
> 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/CAGNvRgAB1W7954%2B%2B4sJ1FWN_
> CPgi4aJrSKPSnEomUFZaz2B0GA%40mail.gmail.com.
>


Especially regarding the class string_view:
How about a class could be declared as 'constexpr', thereby automatically
declaring all its members, functions as well as variables, as 'constexpr'?

-Ren=C3=A9

--=20

=E2=80=9CDubito ergo cogito; cogito ergo sum.
(I doubt, therefore I think; I think therefore I am)=E2=80=9D
Ren=C3=A9 Descartes

--=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/CABBw9zF8qaqWLGGnPVTj3Jx2CsH%3D%3DmphxVvMm%2BLkw=
ytm23igRA%40mail.gmail.com.

--001a113ddafc2494ea0552e133ed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2017-06-26 20:26 GMT+02:00 Daniel Kr=C3=BCgler <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegle=
r@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">2017-06-26 20:19 GMT+02:00 Jonathan M=C3=BCller &lt;<a href=3D"mailto=
:jonathanmueller.dev@gmail.com">jonathanmueller.dev@gmail.com</a><wbr>&gt;:=
<br>
&gt; On <a href=3D"tel:26.06.2017%2019" value=3D"+12606201719">26.06.2017 1=
9</a>:52, Daniel Kr=C3=BCgler wrote:<br>
&gt;&gt;<br>
&gt;&gt; Two thoughts:<br>
&gt;&gt;<br>
&gt;&gt; 1) How do I opt out, if it becomes the default?<br>
&gt;<br>
&gt;<br>
&gt; Why would you want to opt out?<br>
&gt;<br>
&gt; Just write a function as normal. If it can be constexpr, good. Otherwi=
se it<br>
&gt; won&#39;t be constexpr.<br>
<br>
</span>That is not sufficient, because according to the current situation a=
<br>
program can be ill-formed, if a function is marked as constexpr and<br>
some other condition applies. This applies to main() but also to<br>
[dcl.constexpr] p5, just as examples. What I&#39;m trying to say here is:<b=
r>
This is not just as simple as &quot;Just let&#39;s make it the default&quot=
;.<br>
<br>
-Daniel<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAGNvRgAB1W7954%2B%2B4sJ1FWN_C=
Pgi4aJrSKPSnEomUFZaz2B0GA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposal=
s/CAGNvRgAB1W7954%2B%<wbr>2B4sJ1FWN_<wbr>CPgi4aJrSKPSnEomUFZaz2B0GA%<wbr>40=
mail.gmail.com</a>.<br>
</blockquote></div><br><br></div><div class=3D"gmail_extra">Especially rega=
rding the class string_view:<br></div><div class=3D"gmail_extra">How about =
a class could be declared as &#39;constexpr&#39;, thereby automatically dec=
laring all its members, functions as well as variables, as &#39;constexpr&#=
39;?<br><br></div><div class=3D"gmail_extra">-Ren=C3=A9<br clear=3D"all"></=
div><div class=3D"gmail_extra"><br>-- <br><div class=3D"gmail_signature" da=
ta-smartmail=3D"gmail_signature"><br>=E2=80=9CDubito ergo cogito; cogito er=
go sum.<br>(I doubt, therefore I think; I think therefore I am)=E2=80=9D<br=
>Ren=C3=A9 Descartes<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&quot; 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/CABBw9zF8qaqWLGGnPVTj3Jx2CsH%3D%3Dmph=
xVvMm%2BLkwytm23igRA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABBw9zF8qa=
qWLGGnPVTj3Jx2CsH%3D%3DmphxVvMm%2BLkwytm23igRA%40mail.gmail.com</a>.<br />

--001a113ddafc2494ea0552e133ed--

.

> =E5=9C=A8 2017=E5=B9=B46=E6=9C=8827=E6=97=A5=EF=BC=8C02:19=EF=BC=8CJonath=
an M=C3=BCller <jonathanmueller.dev@gmail.com> =E5=86=99=E9=81=93=EF=BC=9A
>=20
> On 26.06.2017 19:52, Daniel Kr=C3=BCgler wrote:
>> Two thoughts:
>> 1) How do I opt out, if it becomes the default?
>=20
> Why would you want to opt out?
>=20
> Just write a function as normal. If it can be constexpr, good. Otherwise =
it won't be constexpr.

Then how can I be sure the function [is meant to be] used in a constant exp=
ression? By=20
'is meant to be' I mean, the author promised the function will keep its con=
stexpr-ness=20
in the future, that is, the constexpr-ness was not by accident.

By make everything constexpr by default without a way to opt out, either:

1) the caller accept the fact that every function he called in constant exp=
ression may=20
stop being constexpr some day, and break his code, or
2) every function that was not initially constexpr have to keep being const=
expr since=20
then.

--=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/B10ACF3E-6232-466B-A85A-D5795034D35B%40outlook.c=
om.

.

------=_Part_1869_855242863.1498503862344
Content-Type: multipart/alternative;
 boundary="----=_Part_1870_1329796846.1498503862345"

------=_Part_1870_1329796846.1498503862345
Content-Type: text/plain; charset="UTF-8"

What about a constexpr expression that would, if possible, recursively
force evaluation of all contained function calls as constant expressions,
and generate a compile-time error if that isn't possible?

constexpr size_t foo = constexpr(strlen("bar")); // 3, or error

This would make any assumptions the caller is making about constexpr-eligiblity
explicit.

What would really be helpful, IMO, is a way to provide both constexpr and
non-constexpr overloads. Although I could see the argument that the
negatives of the perceived increase in boilerplate outweigh the positives
for metaprogramming.

--
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/038e6e4f-0db7-4410-9fc0-473553dff374%40isocpp.org.

------=_Part_1870_1329796846.1498503862345
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>What about a <span style=3D"font-family: courier new,=
monospace;">constexpr</span> expression that would, if possible, recursivel=
y force evaluation of all contained function calls as constant expressions,=
 and generate a compile-time error if that isn&#39;t possible?</div><div><b=
r></div><div><div style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wr=
ap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">constexpr</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> size_t foo </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">strlen</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #080;" class=3D"styled-by-prettify">&quot;bar&quot;</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;=
" class=3D"styled-by-prettify">// 3, or error</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>This w=
ould make any assumptions the caller is making about <span style=3D"font-fa=
mily: courier new,monospace;">constexpr</span>-eligiblity explicit.</div><d=
iv><br></div><div>What would really be helpful, IMO, is a way to provide bo=
th <span style=3D"font-family: courier new,monospace;">constexpr</span> and=
 non-<span style=3D"font-family: courier new,monospace;">constexpr</span> o=
verloads. Although I could see the argument that the negatives of the perce=
ived increase in boilerplate outweigh the positives for metaprogramming.<br=
></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/038e6e4f-0db7-4410-9fc0-473553dff374%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/038e6e4f-0db7-4410-9fc0-473553dff374=
%40isocpp.org</a>.<br />

------=_Part_1870_1329796846.1498503862345--

------=_Part_1869_855242863.1498503862344--

.

------=_Part_1812_1090453160.1498505339728
Content-Type: multipart/alternative;
 boundary="----=_Part_1813_257924073.1498505339728"

------=_Part_1813_257924073.1498505339728
Content-Type: text/plain; charset="UTF-8"

On Monday, June 26, 2017 at 12:04:22 PM UTC-7, Ray Hamel wrote:
>
> What about a constexpr expression that would, if possible, recursively
> force evaluation of all contained function calls as constant expressions,
> and generate a compile-time error if that isn't possible?
>
>
A very primary problem is that one would want the errors for a function
intended to be constexpr to be raised at the time of semantic analysis of
that function itself, not only at call sites.

If a function is meant to be constexpr it _should_ have required markup to
inform both the user and the compiler _at that point in the code_ that the
function must adhere to the rules of constexpr functions.

The problems with needing to mark up tons of member functions of a constant
type are imo indeed better solved by just being able to set a whole class
as constexpr, though of course rules are necessary to support constexpr
types with non-constexpr member functions / constructors (e.g. rules that
constexpr classes have all _eligable_ member functions marked constexpr
implicitly, or adding a noconstexpr or constexpr(false) tag to functions,
or something silly like that.

I do like the idea of a constexpr() expression - or something like it - to
more easily ensure an expression is evaluated at compile time, rather than
having to assign the expression to an otherwise unnecessary constexpr
temporary.

A good part of your complaint is really just an unfortunate bit of C++
grammer: the constexpr goes next to the return type and not on the
function. It'd have been really great for constexpr - and simialr keywords
- to all be after the parameter list so we'd get e.g.: int function()
constexpr { return blah; } // much more obvious I think, but that ship has
sailed

--
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/f787f0bc-cb4b-41de-bef2-732959daf42b%40isocpp.org.

------=_Part_1813_257924073.1498505339728
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, June 26, 2017 at 12:04:22 PM UTC-7, Ray Hamel w=
rote:<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"ltr"><div>Wha=
t about a <span style=3D"font-family:courier new,monospace">constexpr</span=
> expression that would, if possible, recursively force evaluation of all c=
ontained function calls as constant expressions, and generate a compile-tim=
e error if that isn&#39;t possible?</div><div><br></div></div></blockquote>=
<div><br></div><div>A very primary problem is that one would want the error=
s for a function intended to be constexpr to be raised at the time of seman=
tic analysis of that function itself, not only at call sites.</div><div><br=
></div><div>If a function is meant to be constexpr it _should_ have require=
d markup to inform both the user and the compiler _at that point in the cod=
e_ that the function must adhere to the rules of constexpr functions.</div>=
<div><br></div><div>The problems with needing to mark up tons of member fun=
ctions of a constant type are imo indeed better solved by just being able t=
o set a whole class as constexpr, though of course rules are necessary to s=
upport constexpr types with non-constexpr member functions / constructors (=
e.g. rules that constexpr classes have all _eligable_ member functions mark=
ed constexpr implicitly, or adding a noconstexpr or constexpr(false) tag to=
 functions, or something silly like that.</div><div><br></div><div>I do lik=
e the idea of a constexpr() expression - or something like it - to more eas=
ily ensure an expression is evaluated at compile time, rather than having t=
o assign the expression to an otherwise unnecessary constexpr temporary.</d=
iv><div><br></div><div>A good part of your complaint is really just an unfo=
rtunate bit of C++ grammer: the constexpr goes next to the return type and =
not on the function. It&#39;d have been really great for constexpr - and si=
mialr keywords - to all be after the parameter list so we&#39;d get e.g.: i=
nt function() constexpr { return blah; } // much more obvious I think, but =
that ship has sailed</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/f787f0bc-cb4b-41de-bef2-732959daf42b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f787f0bc-cb4b-41de-bef2-732959daf42b=
%40isocpp.org</a>.<br />

------=_Part_1813_257924073.1498505339728--

------=_Part_1812_1090453160.1498505339728--

.

> On 27 Jun 2017, at 03:28, Sean Middleditch <sean.middleditch@gmail.com> w=
rote:
>=20
> [...]
>=20
> A good part of your complaint is really just an unfortunate bit of C++ gr=
ammer: the constexpr goes next to the return type and not on the function. =
It'd have been really great for constexpr - and simialr keywords - to all b=
e after the parameter list so we'd get e.g.: int function() constexpr { ret=
urn blah; } // much more obvious I think, but that ship has sailed

Sorry for getting off the topic but..

IMHO, placing 'constexpr' before the return type makes it a bit clear that =
only the return value (may) be constant, but nothing else (parameter, for e=
xample).

IIRC there have been some discussions / proposals about constexpr parameter=
 in std-discussion / this forum.

btw: It seems to me that the constexpr is still not explicit enough about w=
hether / when a function's return value is constexpr since, even if the fun=
ction is marked as 'constexpr', it can behave in a non-constexpr way when c=
alled with certain parameters if it's implemented that way. e.g.:=20

constexpr int f(int x) { if (x) throw 1; return x; } // f(1) is not constex=
pr.=20

And even if f keeps being 'constexpr', it can behave in a non-constexpr way=
 when called with some different parameters in the future, presumbly withou=
t anyone's notice..

--=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/813FB13E-980D-4575-B128-016BE18F8C40%40outlook.c=
om.

.

On segunda-feira, 26 de junho de 2017 10:47:45 PDT Barry Revzin wrote:
> Over the last few years, we've had this large proliferation of constexpr
> functions - especially after C++14 relaxed what was allowed to be
> constexpr. Now we're in this state where basically any type that is literal
> just has all of its member functions marked constexpr. This ends up being
> really... weird. std::string_view for instance has member functions like:
>
> constexpr void remove_prefix(size_type );
> constexpr void swap(basic_string_view& ) noexcept;

Don't forget the noexcept repetition:

 constexpr void function(...) noexcept(body)
 {
  body;
 }


--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/16652553.ciUozak1qH%40tjmaciei-mobl1.

.

------=_Part_2106_1727372151.1498517014187
Content-Type: multipart/alternative;
 boundary="----=_Part_2107_1928542221.1498517014187"

------=_Part_2107_1928542221.1498517014187
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Monday, June 26, 2017 at 11:39:17 AM UTC-7, d25f...@outlook.com wrote:
>
>
> > =E5=9C=A8 2017=E5=B9=B46=E6=9C=8827=E6=97=A5=EF=BC=8C02:19=EF=BC=8CJona=
than M=C3=BCller <jonathanm...@gmail.com <javascript:>>=20
> =E5=86=99=E9=81=93=EF=BC=9A=20
> >=20
> > On 26.06.2017 19:52, Daniel Kr=C3=BCgler wrote:=20
> >> Two thoughts:=20
> >> 1) How do I opt out, if it becomes the default?=20
> >=20
> > Why would you want to opt out?=20
> >=20
> > Just write a function as normal. If it can be constexpr, good. Otherwis=
e=20
> it won't be constexpr.=20
>
> Then how can I be sure the function [is meant to be] used in a constant=
=20
> expression? By=20
> 'is meant to be' I mean, the author promised the function will keep its=
=20
> constexpr-ness=20
> in the future, that is, the constexpr-ness was not by accident.=20
>
> By make everything constexpr by default without a way to opt out, either:=
=20
>
> 1) the caller accept the fact that every function he called in constant=
=20
> expression may=20
> stop being constexpr some day, and break his code, or=20
> 2) every function that was not initially constexpr have to keep being=20
> constexpr since=20
> then.=20
>

This is a fair point.  But surely the counter-argument is that very few=20
things in C++ work this way today (constexpr, const, and noexcept being the=
=20
three exceptions I can think of, and all three of them famously leading to=
=20
tons of boilerplate).

The usual way to handle "documented invariants" or "requirements" of this=
=20
nature is to annotate them in the source code with either comments or=20
static_asserts:

class MyFoo {
    int one() const;  // I promise this will never stop being callable on a=
=20
const object
    constexpr int two();  // I promise this will never stop being callable=
=20
in a constexpr context
    int three() noexcept;  // I promise this will never stop being nothrow
    int four();
};
static_assert(is_trivially_copy_constructible_v<MyFoo>);  // I promise this=
=20
will never stop being trivially copy-constructible
static_assert(is_aggregate_v<MyFoo>);  // I promise this will never stop=20
being memberwise initializable
static_assert(sizeof(&MyFoo::four));  // I promise this function will never=
=20
be overloaded
static_assert(is_same_v<decltype(declval<MyFoo&>().four(), int>);  // I=20
promise this return type will never change

and so on and so forth.  If we had the syntax for it, then we could easily=
=20
annotate our source code with

static_assert(is_constexpr_constructible_v<MyFoo>);  // I promise this will=
=20
never stop being constexpr constructible
static_assert(constexpr(MyFoo().four()));  // I promise this expression=20
will never stop being evaluable in a constexpr context

Const and noexcept are actually special cases in two related ways: they=20
participate in name-mangling *and* need to match up across module=20
boundaries. You can declare a function "noexcept" without ever seeing its=
=20
definition.  But this is not true for constexpr; a function with no visible=
=20
definition cannot possibly be evaluated at compile time!

(A) The constexpr-ness of a function is part of its API.
(B) If a function is not inline, then it cannot be constexpr.
(C) If a function is inline, then its definition is part of its API.
(QED?): We can let the constexpr-ness of a function be deduced from its=20
definition, without changing what is part of its API.


So yeah, I think that if your client code relies on the constexpr-ness of a=
=20
function that isn't specifically annotated as such, your code is just as=20
broken as client code that relies on the trivial-ness or nothrow-ness of a=
=20
function that isn't specifically annotated as such.  But does that mean=20
that we need special language *keywords* for annotating constexpr-ness,=20
trivial-ness, or nothrow-ness? IMHO perhaps not.

my $.02,
Arthur

--=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/73f36508-4ae8-4d5f-9681-a04ce2f41dee%40isocpp.or=
g.

------=_Part_2107_1928542221.1498517014187
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, June 26, 2017 at 11:39:17 AM UTC-7, d25f...@out=
look.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; =E5=9C=A8 2017=E5=B9=B46=E6=9C=8827=E6=97=A5=EF=BC=8C02:19=EF=BC=
=8CJonathan M=C3=BCller &lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"FMKSZRTyAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jonathanm...@gmail.com</a><wbr>&gt; =E5=86=99=E9=81=
=93=EF=BC=9A
<br>&gt;=20
<br>&gt; On 26.06.2017 19:52, Daniel Kr=C3=BCgler wrote:
<br>&gt;&gt; Two thoughts:
<br>&gt;&gt; 1) How do I opt out, if it becomes the default?
<br>&gt;=20
<br>&gt; Why would you want to opt out?
<br>&gt;=20
<br>&gt; Just write a function as normal. If it can be constexpr, good. Oth=
erwise it won&#39;t be constexpr.
<br>
<br>Then how can I be sure the function [is meant to be] used in a constant=
 expression? By=20
<br>&#39;is meant to be&#39; I mean, the author promised the function will =
keep its constexpr-ness=20
<br>in the future, that is, the constexpr-ness was not by accident.
<br>
<br>By make everything constexpr by default without a way to opt out, eithe=
r:
<br>
<br>1) the caller accept the fact that every function he called in constant=
 expression may=20
<br>stop being constexpr some day, and break his code, or
<br>2) every function that was not initially constexpr have to keep being c=
onstexpr since=20
<br>then.
<br></blockquote><div><br></div><div>This is a fair point. =C2=A0But surely=
 the counter-argument is that very few things in C++ work this way today (c=
onstexpr, const, and noexcept being the three exceptions I can think of, an=
d all three of them famously leading to tons of boilerplate).</div><div><br=
></div><div>The usual way to handle &quot;documented invariants&quot; or &q=
uot;requirements&quot; of this nature is to annotate them in the source cod=
e with either comments or static_asserts:</div><div><br></div><div>class My=
Foo {</div><div>=C2=A0 =C2=A0 int one() const; =C2=A0// I promise this will=
 never stop being callable on a const object</div><div>=C2=A0 =C2=A0 conste=
xpr int two(); =C2=A0// I promise this will never stop being callable in a =
constexpr context</div><div>=C2=A0 =C2=A0 int three() noexcept; =C2=A0// I =
promise this will never stop being nothrow</div><div>=C2=A0 =C2=A0 int four=
();</div><div>};</div><div>static_assert(is_trivially_copy_constructible_v&=
lt;MyFoo&gt;); =C2=A0// I promise this will never stop being trivially copy=
-constructible</div><div><div>static_assert(is_aggregate_v&lt;MyFoo&gt;); =
=C2=A0// I promise this will never stop being memberwise initializable</div=
></div><div><div>static_assert(sizeof(&amp;MyFoo::four)); =C2=A0// I promis=
e this function will never be overloaded</div></div><div>static_assert(is_s=
ame_v&lt;decltype(declval&lt;MyFoo&amp;&gt;().four(), int&gt;); =C2=A0// I =
promise this return type will never change</div><div><br></div><div>and so =
on and so forth. =C2=A0If we had the syntax for it, then we could easily an=
notate our source code with</div><div><br></div><div>static_assert(is_const=
expr_constructible_v&lt;MyFoo&gt;); =C2=A0// I promise this will never stop=
 being constexpr constructible</div><div>static_assert(constexpr(MyFoo().fo=
ur())); =C2=A0// I promise this expression will never stop being evaluable =
in a constexpr context</div><div><br></div><div>Const and noexcept are actu=
ally special cases in two related ways: they participate in name-mangling <=
i>and</i> need to match up across module boundaries. You can declare a func=
tion &quot;noexcept&quot; without ever seeing its definition. =C2=A0But thi=
s is not true for constexpr; a function with no visible definition cannot p=
ossibly be evaluated at compile time!</div><div><br></div><div>(A) The cons=
texpr-ness of a function is part of its API.</div><div>(B) If a function is=
 not inline, then it cannot be constexpr.<br></div><div>(C) If a function i=
s inline, then its definition is part of its API.</div><div>(QED?): We can =
let the constexpr-ness of a function be deduced from its definition, withou=
t changing what is part of its API.</div><div><br></div><div><br></div><div=
>So yeah, I think that if your client code relies on the constexpr-ness of =
a function that isn&#39;t specifically annotated as such, your code is just=
 as broken as client code that relies on the trivial-ness or nothrow-ness o=
f a function that isn&#39;t specifically annotated as such. =C2=A0But does =
that mean that we need special language <i>keywords</i> for annotating cons=
texpr-ness, trivial-ness, or nothrow-ness? IMHO perhaps not.</div><div><br>=
</div><div>my $.02,</div><div>Arthur</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/73f36508-4ae8-4d5f-9681-a04ce2f41dee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/73f36508-4ae8-4d5f-9681-a04ce2f41dee=
%40isocpp.org</a>.<br />

------=_Part_2107_1928542221.1498517014187--

------=_Part_2106_1727372151.1498517014187--

.

2017-06-26 20:26 GMT+02:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com>:
> 2017-06-26 20:19 GMT+02:00 Jonathan M=C3=BCller <jonathanmueller.dev@gmai=
l.com>:
>> On 26.06.2017 19:52, Daniel Kr=C3=BCgler wrote:
>>>
>>> Two thoughts:
>>>
>>> 1) How do I opt out, if it becomes the default?
>>
>>
>> Why would you want to opt out?
>>
>> Just write a function as normal. If it can be constexpr, good. Otherwise=
 it
>> won't be constexpr.
>
> That is not sufficient, because according to the current situation a
> program can be ill-formed, if a function is marked as constexpr and
> some other condition applies. This applies to main() but also to
> [dcl.constexpr] p5, just as examples. What I'm trying to say here is:
> This is not just as simple as "Just let's make it the default".
>

Daniel, I'm not convinced of these examples. If the program would be
ill-formed for an implicitly constexpr function, it just won't mark
the function implicitly constexpr. Can you give an example where that
strategy would fail?

Would implicitly marking a function constexpr cost too much resources
on the compiler? I Imagine the compiler would possibly need to keep
more information in the AST for being able to constexpr it. Is that
the reason why you have to explicitly opt-in to 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/CANu6V4X9fRSFCCH3Ui7Rhu1FAA9vm%3DPZdoab%2Bt8b96T=
mNU0g8A%40mail.gmail.com.

.

------=_Part_412_2103240153.1498545515871
Content-Type: multipart/alternative;
 boundary="----=_Part_413_1170861069.1498545515871"

------=_Part_413_1170861069.1498545515871
Content-Type: text/plain; charset="UTF-8"

Is constexpr mark a guarantee that function can be evaluated in compile
time? How about the story with constexpr string_view(const char * )?

https://developercommunity.visualstudio.com/content/problem/24487/constexpr-stdstring-view-from-string-literal.html

--
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/4e1ff6f7-c725-4d8d-bbe5-f1ec08b9f1c7%40isocpp.org.

------=_Part_413_1170861069.1498545515871
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is constexpr mark a guarantee that function can be evaluat=
ed in compile time? How about the story with constexpr string_view(const ch=
ar * )?<br><br>https://developercommunity.visualstudio.com/content/problem/=
24487/constexpr-stdstring-view-from-string-literal.html<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/4e1ff6f7-c725-4d8d-bbe5-f1ec08b9f1c7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4e1ff6f7-c725-4d8d-bbe5-f1ec08b9f1c7=
%40isocpp.org</a>.<br />

------=_Part_413_1170861069.1498545515871--

------=_Part_412_2103240153.1498545515871--

.

2017-06-27 8:19 GMT+02:00 'Johannes Schaub' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org>:
> Daniel, I'm not convinced of these examples. If the program would be
> ill-formed for an implicitly constexpr function, it just won't mark
> the function implicitly constexpr. Can you give an example where that
> strategy would fail?

I'm merely criticizing the seemingly simple idea of changing the
default, because it overlooks the complexity details of the current
rules and I'm not able to understand the full consequences without
seeing the full proposal. And given that there is still strong
resistance against accepting

http://cplusplus.github.io/LWG/lwg-active.html#2892

I expect that to become a controversial request, but it surely depends
on the actual content of a corresponding proposal.

- Daniel

--
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/CAGNvRgDzeJMg_8hFquigQ7pW717cYfPnxH0d0eCZWrLA0Sd2vw%40mail.gmail.com.

.

------=_Part_2399_695952577.1498573155969
Content-Type: multipart/alternative;
 boundary="----=_Part_2400_1463010542.1498573155970"

------=_Part_2400_1463010542.1498573155970
Content-Type: text/plain; charset="UTF-8"

Have you already seen this?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0639r0.html

Standard Library containers miss constexpr

   - *Solution: *It is simple to add constexpr all around the container
   declaration

--
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/f73d98b0-ada5-411a-909a-0c1272c1db0b%40isocpp.org.

------=_Part_2400_1463010542.1498573155970
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Have you already seen this?<br>http://www.open-std.org/jtc=
1/sc22/wg21/docs/papers/2017/p0639r0.html<br><br><span style=3D"color: rgb(=
0, 0, 0); font-family: Verdana; font-size: medium; font-style: normal; font=
-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal;=
 letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; te=
xt-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -web=
kit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-deco=
ration-style: initial; text-decoration-color: initial; display: inline !imp=
ortant; float: none;">Standard Library containers miss<span>=C2=A0</span></=
span><code style=3D"color: rgb(0, 0, 0); font-style: normal; font-variant-l=
igatures: normal; font-variant-caps: normal; font-weight: normal; letter-sp=
acing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-s=
troke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-sty=
le: initial; text-decoration-color: initial;">constexpr</code><span style=
=3D"color: rgb(0, 0, 0); font-family: Verdana; font-size: medium; font-styl=
e: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-=
weight: normal; letter-spacing: normal; orphans: 2; text-align: left; text-=
indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spa=
cing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, =
255); text-decoration-style: initial; text-decoration-color: initial; displ=
ay: inline !important; float: none;"></span><ul style=3D"color: rgb(0, 0, 0=
); font-family: Verdana; font-size: medium; font-style: normal; font-varian=
t-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter=
-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-tran=
sform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-=
style: initial; text-decoration-color: initial;"><li><b>Solution:<span>=C2=
=A0</span></b>It is simple to add<span>=C2=A0</span><code>constexpr</code><=
span>=C2=A0</span>all around the container declaration</li></ul></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/f73d98b0-ada5-411a-909a-0c1272c1db0b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f73d98b0-ada5-411a-909a-0c1272c1db0b=
%40isocpp.org</a>.<br />

------=_Part_2400_1463010542.1498573155970--

------=_Part_2399_695952577.1498573155969--

.

2017-06-27 16:19 GMT+02:00 Victor Dyachenko <victor.dyachenko@gmail.com>:
> Have you already seen this?
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0639r0.html
>
> Standard Library containers miss constexpr
>
> Solution: It is simple to add constexpr all around the container declaration

Yes, I have read the paper, but that paper alone is neither a proof of
the OP's suggestion to work in all cases nor does the paper suggest
this approach. It is a very nice work, though.

- Daniel

--
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/CAGNvRgCwNdgryzUTvtMG6hdXvW3WCt4Gk%2BoDP_at8qgxPQ9c4w%40mail.gmail.com.

.