Topic: constexpr if, and a little bit more control over constexpr.
Author: Andrei L <aendaerel@gmail.com>
Date: Tue, 29 Mar 2016 20:51:34 -0700 (PDT)
Raw View
------=_Part_5230_511096403.1459309894927
Content-Type: multipart/alternative;
boundary="----=_Part_5231_984538862.1459309894927"
------=_Part_5231_984538862.1459309894927
Content-Type: text/plain; charset=UTF-8
Hello.
At the last committee meeting, there was made a decision to change syntax
from 'constexpr if' to 'if constexpr', and while this decision has it's
reasons, there is minor issue with it. It is somewhat unclear, what 'if
constexpr' is means. I understand what it means but still, I feel urge to
read 'if constexpr ... else ....' as: "if constexpr, then do this, if not
constexpr, do that." This issue can be solved, if you think about
'constexpr', as part of condition, as a requirement that condition must be
constexpr, but syntactically, it is placed outside parentheses, closer to
an 'if', than to condition. If we'd have something like 'constexpr (
expression )' in the language, then that form of 'if' could've be explained
as 'if (constexpr (condition))', and we could say that since parentheses
around *constexpr-condition* are redundant, we are allowed to drop them.
That made me think: "Why can't we have that constexpr-expression?" Given
that there is desire to be able to require compile-time evaluation, I find
it quite strange that we don't have something like that already.
Consider:
constexpr int get_val();
void foo(int &);
void bar()
{
constexpr int val = get_val();
foo(val);
}
So, we have constexpr functions in the language, and they are not required
to be called at compile time. To make sure, that we don't pay cost at
run-time for what we can do at compile-time, we assign result of a function
call to a constexpr variable. But, constexpr implies const, so presented
code will not compile. GCC produces an error: "binding 'const int' to 'int
&' discards qualifiers". To overcome that issue we can introduce a
temporary:
void bar()
{
constexpr int tmp = get_val();
int val = tmp;
foo(val);
}
Problem solved, but now, we have unneeded and unwanted variable, which has
no cost, but it's still there, in the code, takes free space. If we'd had
*constexpr-expression* in a language*,* we could've solved our problem like
this:
void bar()
{
int val = constexpr (get_val());
foo(val);
}
What *constexpr-expression* could do? It could force compile-time
evaluation of an expression. If evaluation at compile-time is not possible,
then we'd get loud failure, instead of possible run-time errors, or not
matching expectations.
So, now there is no temporaries, only what's needed, and no run-time cost,
but, there is also one more question: "Do we need parentheses around
expression in *constexpr-expression*?"
int val = constexpr get_val();
Without parentheses, 'constexpr' looks like a prefix to an expression, what
I find nice, and less noisy.
Coming back to 'if constexpr'; If thinking that 'constexpr' is closer to
condition than to an 'if' is the right way to think, then we can make one
step further and put 'constexpr' inside parentheses.
if (constexpr condition) {
...
}
It's far from how 'static_if' or 'constexpr if' looks, but nor 'if
constexpr' looks like them. This syntax, in my opinion, is less ambiguous
in it's "if-ness", then 'if constexpr'.
Thoughts?
--
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/33d19c42-848a-4952-9724-26b98790742b%40isocpp.org.
------=_Part_5231_984538862.1459309894927
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello.<br><br>At the last committee meeting, there was mad=
e a decision to change syntax from 'constexpr if' to 'if conste=
xpr', and while this decision has it's reasons, there is minor issu=
e with it. It is somewhat unclear, what 'if constexpr' is means. I =
understand what it means but still, I feel urge to read 'if constexpr .=
... else ....' as: "if constexpr, then do this, if not constexpr, d=
o that." This issue can be solved, if you think about 'constexpr&#=
39;, as part of condition, as a requirement that condition must be constexp=
r, but syntactically, it is placed outside parentheses, closer to an 'i=
f', than to condition. If we'd have something like 'constexpr (=
expression )' in the language, then that form of 'if' could=
9;ve be explained as 'if (constexpr (condition))', and we could sa=
y that since parentheses around <i>constexpr-condition</i> are redundant, w=
e are allowed to drop them.<br><br>That made me think: "Why can't =
we have that constexpr-expression?" Given that there is desire to be a=
ble to require compile-time evaluation, I find it quite strange that we don=
't have something like that already.<br><br>Consider:<br><br><div style=
=3D"margin-left: 40px;"><span style=3D"font-family: courier new,monospace;"=
>constexpr int get_val();</span><br><span style=3D"font-family: courier new=
,monospace;"></span><br><span style=3D"font-family: courier new,monospace;"=
>void foo(int &);</span><br><span style=3D"font-family: courier new,mon=
ospace;">void bar()</span><br><span style=3D"font-family: courier new,monos=
pace;">{</span><br><span style=3D"font-family: courier new,monospace;">=C2=
=A0 constexpr int val =3D get_val();</span><br><span style=3D"font-family: =
courier new,monospace;">=C2=A0 foo(val);</span><br><span style=3D"font-fami=
ly: courier new,monospace;">}</span><br></div><br>So, we have constexpr fun=
ctions in the language, and they are not required to be called at compile t=
ime. To make sure, that we don't pay cost at run-time for what we can d=
o at compile-time, we assign result of a function call to a constexpr varia=
ble. But, constexpr implies const, so presented code will not compile. GCC =
produces an error: "binding 'const int' to 'int &'=
discards qualifiers". To overcome that issue we can introduce a tempo=
rary:<br><span style=3D"font-family: arial,sans-serif;"><br></span><div sty=
le=3D"margin-left: 40px;"><span style=3D"font-family: courier new,monospace=
;">void bar()<br>{<br>=C2=A0 constexpr int tmp =3D get_val();<br>=C2=A0 int=
val =3D tmp;<br>=C2=A0 foo(val);<br>}</span><br><span style=3D"font-family=
: arial,sans-serif;"></span></div><span style=3D"font-family: arial,sans-se=
rif;"><br>Problem solved, but now, we have unneeded and unwanted variable, =
which has no cost, but it's still there, in the code, takes free space.=
If we'd had <i>constexpr-expression</i> in a language<i>,</i> we could=
've solved our problem like this:<br><br></span><div style=3D"margin-le=
ft: 40px;"><span style=3D"font-family: arial,sans-serif;"><span style=3D"fo=
nt-family: courier new,monospace;">void bar()</span></span><br><span style=
=3D"font-family: arial,sans-serif;"><span style=3D"font-family: courier new=
,monospace;">{</span></span><br><span style=3D"font-family: arial,sans-seri=
f;"><span style=3D"font-family: courier new,monospace;">=C2=A0 int val =3D =
constexpr (get_val());</span></span><br><span style=3D"font-family: arial,s=
ans-serif;"><span style=3D"font-family: courier new,monospace;">=C2=A0 foo(=
val);</span></span><br><span style=3D"font-family: arial,sans-serif;"><span=
style=3D"font-family: courier new,monospace;">}</span></span><br><span sty=
le=3D"font-family: arial,sans-serif;"></span></div><br><span style=3D"font-=
family: arial,sans-serif;"><span style=3D"font-family: arial,sans-serif;">W=
hat=20
<i>constexpr-expression</i> could do? It could force </span></span><span st=
yle=3D"font-family: arial,sans-serif;"><span style=3D"font-family: arial,sa=
ns-serif;"><span style=3D"font-family: arial,sans-serif;"><span style=3D"fo=
nt-family: arial,sans-serif;">compile-time evaluation of </span></span>an e=
xpression. If evaluation at compile-time is not possible, then we'd get=
loud failure, instead of possible run-time errors, or not matching expecta=
tions.<br><br>So, now t</span>here is no temporaries, only what's neede=
d, and no run-time cost, but, there is also one more question: "Do we =
need parentheses around expression in <i>constexpr-expression</i>?"<br=
><br></span><div style=3D"margin-left: 40px;"><span style=3D"font-family: a=
rial,sans-serif;"><span style=3D"font-family: courier new,monospace;">int v=
al =3D constexpr get_val();</span></span><br><span style=3D"font-family: ar=
ial,sans-serif;"></span></div><span style=3D"font-family: arial,sans-serif;=
"><br>Without parentheses, 'constexpr' looks like a prefix to an ex=
pression, what I find nice, and less noisy.<br><br>Coming back to 'if c=
onstexpr'; If thinking that 'constexpr' is closer to condition =
than to an 'if' is the right way to think, then we </span><span sty=
le=3D"font-family: arial,sans-serif;"><span style=3D"font-family: arial,san=
s-serif;">can </span>make one step further and put 'constexpr' insi=
de parentheses.<br><br></span><div style=3D"margin-left: 40px;"><span style=
=3D"font-family: courier new,monospace;">if (constexpr condition) {<br>=C2=
=A0 ...<br>}</span><br><span style=3D"font-family: arial,sans-serif;"></spa=
n></div><span style=3D"font-family: arial,sans-serif;"><br>It's far fro=
m how 'static_if' or 'constexpr if' looks, but nor 'if =
constexpr' looks like them. This syntax, in my opinion, is less ambiguo=
us in it's "if-ness", then 'if constexpr'.<br><br>Tho=
ughts?<br></span><span style=3D"font-family: arial,sans-serif;"><span style=
=3D"font-family: courier new,monospace;"></span></span><div style=3D"margin=
-left: 40px;"><span style=3D"font-family: arial,sans-serif;"></span></div><=
span style=3D"font-family: courier new,monospace;"></span></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/33d19c42-848a-4952-9724-26b98790742b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/33d19c42-848a-4952-9724-26b98790742b=
%40isocpp.org</a>.<br />
------=_Part_5231_984538862.1459309894927--
------=_Part_5230_511096403.1459309894927
Content-Type: text/plain; charset=US-ASCII; name=possible-grammar.txt
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=possible-grammar.txt
X-Attachment-Id: 92b2c301-8eee-4626-af29-a79d52d06ebf
Content-ID: <92b2c301-8eee-4626-af29-a79d52d06ebf>
selection-statement:
if ( constexpr-condition ) statement
if ( constexpr-condition ) statement else statement
constexpr-condition:
constexpr-expression
attribute-specifier-seq opt constexpr decl-specifier-seq declarator = initializer-clause
attribute-specifier-seq opt constexpr decl-specifier-seq declarator braced-init-list
constexpr-expression:
constexpr assignment-expression
expression:
constexpr-expression
expression, constexpr-expression
------=_Part_5230_511096403.1459309894927--
.
Author: bruno.manga95@gmail.com
Date: Wed, 30 Mar 2016 02:04:49 -0700 (PDT)
Raw View
------=_Part_6280_561054140.1459328690091
Content-Type: multipart/alternative;
boundary="----=_Part_6281_351612838.1459328690092"
------=_Part_6281_351612838.1459328690092
Content-Type: text/plain; charset=UTF-8
Would that be allowed to work on constexpr function parameters?
constexpr int bar (int x)
{
return x;
}
constexpr int foo (int x)
{
constexpr int j = constexpr (x);
return bar(j);
}
int x = constexpr foo(11);
On Wednesday, 30 March 2016 04:51:35 UTC+1, Andrei L wrote:
>
> Hello.
>
> At the last committee meeting, there was made a decision to change syntax
> from 'constexpr if' to 'if constexpr', and while this decision has it's
> reasons, there is minor issue with it. It is somewhat unclear, what 'if
> constexpr' is means. I understand what it means but still, I feel urge to
> read 'if constexpr ... else ....' as: "if constexpr, then do this, if not
> constexpr, do that." This issue can be solved, if you think about
> 'constexpr', as part of condition, as a requirement that condition must be
> constexpr, but syntactically, it is placed outside parentheses, closer to
> an 'if', than to condition. If we'd have something like 'constexpr (
> expression )' in the language, then that form of 'if' could've be explained
> as 'if (constexpr (condition))', and we could say that since parentheses
> around *constexpr-condition* are redundant, we are allowed to drop them.
>
> That made me think: "Why can't we have that constexpr-expression?" Given
> that there is desire to be able to require compile-time evaluation, I find
> it quite strange that we don't have something like that already.
>
> Consider:
>
> constexpr int get_val();
>
> void foo(int &);
> void bar()
> {
> constexpr int val = get_val();
> foo(val);
> }
>
> So, we have constexpr functions in the language, and they are not required
> to be called at compile time. To make sure, that we don't pay cost at
> run-time for what we can do at compile-time, we assign result of a function
> call to a constexpr variable. But, constexpr implies const, so presented
> code will not compile. GCC produces an error: "binding 'const int' to 'int
> &' discards qualifiers". To overcome that issue we can introduce a
> temporary:
>
> void bar()
> {
> constexpr int tmp = get_val();
> int val = tmp;
> foo(val);
> }
>
> Problem solved, but now, we have unneeded and unwanted variable, which has
> no cost, but it's still there, in the code, takes free space. If we'd had
> *constexpr-expression* in a language*,* we could've solved our problem
> like this:
>
> void bar()
> {
> int val = constexpr (get_val());
> foo(val);
> }
>
> What *constexpr-expression* could do? It could force compile-time
> evaluation of an expression. If evaluation at compile-time is not
> possible, then we'd get loud failure, instead of possible run-time errors,
> or not matching expectations.
>
> So, now there is no temporaries, only what's needed, and no run-time
> cost, but, there is also one more question: "Do we need parentheses around
> expression in *constexpr-expression*?"
>
> int val = constexpr get_val();
>
> Without parentheses, 'constexpr' looks like a prefix to an expression,
> what I find nice, and less noisy.
>
> Coming back to 'if constexpr'; If thinking that 'constexpr' is closer to
> condition than to an 'if' is the right way to think, then we can make one
> step further and put 'constexpr' inside parentheses.
>
> if (constexpr condition) {
> ...
> }
>
> It's far from how 'static_if' or 'constexpr if' looks, but nor 'if
> constexpr' looks like them. This syntax, in my opinion, is less ambiguous
> in it's "if-ness", then 'if constexpr'.
>
> Thoughts?
>
--
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/1fdbd2bc-9f4d-479c-b987-028ef4a32d15%40isocpp.org.
------=_Part_6281_351612838.1459328690092
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Would that be allowed to work on constexpr function parame=
ters?<div><br></div><div><div class=3D"prettyprint" style=3D"border: 1px so=
lid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 2=
50, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span =
style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> bar </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettify">retu=
rn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #00=
8;" 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">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> foo </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =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">int</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> j </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">constexpr</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</s=
pan><span style=3D"color: #660;" 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"><br>=C2=A0 =C2=A0 =C2=A0</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> bar</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">j</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"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x <=
/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 styl=
e=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">11</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span></div></code></div><div><div><br></div><di=
v>=C2=A0</div><br>On Wednesday, 30 March 2016 04:51:35 UTC+1, Andrei L wro=
te:<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">Hello.<br>=
<br>At the last committee meeting, there was made a decision to change synt=
ax from 'constexpr if' to 'if constexpr', and while this de=
cision has it's reasons, there is minor issue with it. It is somewhat u=
nclear, what 'if constexpr' is means. I understand what it means bu=
t still, I feel urge to read 'if constexpr ... else ....' as: "=
;if constexpr, then do this, if not constexpr, do that." This issue ca=
n be solved, if you think about 'constexpr', as part of condition, =
as a requirement that condition must be constexpr, but syntactically, it is=
placed outside parentheses, closer to an 'if', than to condition. =
If we'd have something like 'constexpr ( expression )' in the l=
anguage, then that form of 'if' could've be explained as '=
if (constexpr (condition))', and we could say that since parentheses ar=
ound <i>constexpr-condition</i> are redundant, we are allowed to drop them.=
<br><br>That made me think: "Why can't we have that constexpr-expr=
ession?" Given that there is desire to be able to require compile-time=
evaluation, I find it quite strange that we don't have something like =
that already.<br><br>Consider:<br><br><div style=3D"margin-left:40px"><span=
style=3D"font-family:courier new,monospace">constexpr int get_val();</span=
><br><span style=3D"font-family:courier new,monospace"></span><br><span sty=
le=3D"font-family:courier new,monospace">void foo(int &);</span><br><sp=
an style=3D"font-family:courier new,monospace">void bar()</span><br><span s=
tyle=3D"font-family:courier new,monospace">{</span><br><span style=3D"font-=
family:courier new,monospace">=C2=A0 constexpr int val =3D get_val();</span=
><br><span style=3D"font-family:courier new,monospace">=C2=A0 foo(val);</sp=
an><br><span style=3D"font-family:courier new,monospace">}</span><br></div>=
<br>So, we have constexpr functions in the language, and they are not requi=
red to be called at compile time. To make sure, that we don't pay cost =
at run-time for what we can do at compile-time, we assign result of a funct=
ion call to a constexpr variable. But, constexpr implies const, so presente=
d code will not compile. GCC produces an error: "binding 'const in=
t' to 'int &' discards qualifiers". To overcome that i=
ssue we can introduce a temporary:<br><span style=3D"font-family:arial,sans=
-serif"><br></span><div style=3D"margin-left:40px"><span style=3D"font-fami=
ly:courier new,monospace">void bar()<br>{<br>=C2=A0 constexpr int tmp =3D g=
et_val();<br>=C2=A0 int val =3D tmp;<br>=C2=A0 foo(val);<br>}</span><br><sp=
an style=3D"font-family:arial,sans-serif"></span></div><span style=3D"font-=
family:arial,sans-serif"><br>Problem solved, but now, we have unneeded and =
unwanted variable, which has no cost, but it's still there, in the code=
, takes free space. If we'd had <i>constexpr-expression</i> in a langua=
ge<i>,</i> we could've solved our problem like this:<br><br></span><div=
style=3D"margin-left:40px"><span style=3D"font-family:arial,sans-serif"><s=
pan style=3D"font-family:courier new,monospace">void bar()</span></span><br=
><span style=3D"font-family:arial,sans-serif"><span style=3D"font-family:co=
urier new,monospace">{</span></span><br><span style=3D"font-family:arial,sa=
ns-serif"><span style=3D"font-family:courier new,monospace">=C2=A0 int val =
=3D constexpr (get_val());</span></span><br><span style=3D"font-family:aria=
l,sans-serif"><span style=3D"font-family:courier new,monospace">=C2=A0 foo(=
val);</span></span><br><span style=3D"font-family:arial,sans-serif"><span s=
tyle=3D"font-family:courier new,monospace">}</span></span><br><span style=
=3D"font-family:arial,sans-serif"></span></div><br><span style=3D"font-fami=
ly:arial,sans-serif"><span style=3D"font-family:arial,sans-serif">What=20
<i>constexpr-expression</i> could do? It could force </span></span><span st=
yle=3D"font-family:arial,sans-serif"><span style=3D"font-family:arial,sans-=
serif"><span style=3D"font-family:arial,sans-serif"><span style=3D"font-fam=
ily:arial,sans-serif">compile-time evaluation of </span></span>an expressio=
n. If evaluation at compile-time is not possible, then we'd get loud fa=
ilure, instead of possible run-time errors, or not matching expectations.<b=
r><br>So, now t</span>here is no temporaries, only what's needed, and n=
o run-time cost, but, there is also one more question: "Do we need par=
entheses around expression in <i>constexpr-expression</i>?"<br><br></s=
pan><div style=3D"margin-left:40px"><span style=3D"font-family:arial,sans-s=
erif"><span style=3D"font-family:courier new,monospace">int val =3D constex=
pr get_val();</span></span><br><span style=3D"font-family:arial,sans-serif"=
></span></div><span style=3D"font-family:arial,sans-serif"><br>Without pare=
ntheses, 'constexpr' looks like a prefix to an expression, what I f=
ind nice, and less noisy.<br><br>Coming back to 'if constexpr'; If =
thinking that 'constexpr' is closer to condition than to an 'if=
' is the right way to think, then we </span><span style=3D"font-family:=
arial,sans-serif"><span style=3D"font-family:arial,sans-serif">can </span>m=
ake one step further and put 'constexpr' inside parentheses.<br><br=
></span><div style=3D"margin-left:40px"><span style=3D"font-family:courier =
new,monospace">if (constexpr condition) {<br>=C2=A0 ...<br>}</span><br><spa=
n style=3D"font-family:arial,sans-serif"></span></div><span style=3D"font-f=
amily:arial,sans-serif"><br>It's far from how 'static_if' or &#=
39;constexpr if' looks, but nor 'if constexpr' looks like them.=
This syntax, in my opinion, is less ambiguous in it's "if-ness&qu=
ot;, then 'if constexpr'.<br><br>Thoughts?<br></span><span style=3D=
"font-family:arial,sans-serif"><span style=3D"font-family:courier new,monos=
pace"></span></span><div style=3D"margin-left:40px"><span style=3D"font-fam=
ily:arial,sans-serif"></span></div><span style=3D"font-family:courier new,m=
onospace"></span></div></blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1fdbd2bc-9f4d-479c-b987-028ef4a32d15%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1fdbd2bc-9f4d-479c-b987-028ef4a32d15=
%40isocpp.org</a>.<br />
------=_Part_6281_351612838.1459328690092--
------=_Part_6280_561054140.1459328690091--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 30 Mar 2016 13:00:55 -0700
Raw View
On Tue, Mar 29, 2016 at 8:51 PM, Andrei L <aendaerel@gmail.com> wrote:
> Hello.
>
> At the last committee meeting, there was made a decision to change syntax
> from 'constexpr if' to 'if constexpr', and while this decision has it's
> reasons, there is minor issue with it. It is somewhat unclear, what 'if
> constexpr' is means. I understand what it means but still, I feel urge to
> read 'if constexpr ... else ....' as: "if constexpr, then do this, if not
> constexpr, do that." This issue can be solved, if you think about
> 'constexpr', as part of condition, as a requirement that condition must be
> constexpr, but syntactically, it is placed outside parentheses, closer to an
> 'if', than to condition. If we'd have something like 'constexpr ( expression
> )' in the language, then that form of 'if' could've be explained as 'if
> (constexpr (condition))', and we could say that since parentheses around
> constexpr-condition are redundant, we are allowed to drop them.
>
> That made me think: "Why can't we have that constexpr-expression?" Given
> that there is desire to be able to require compile-time evaluation, I find
> it quite strange that we don't have something like that already.
>
> Consider:
>
> constexpr int get_val();
>
> void foo(int &);
> void bar()
> {
> constexpr int val = get_val();
You can do this:
constexpr int &&val = get_val();
> foo(val);
> }
>
> So, we have constexpr functions in the language, and they are not required
> to be called at compile time. To make sure, that we don't pay cost at
> run-time for what we can do at compile-time, we assign result of a function
> call to a constexpr variable. But, constexpr implies const, so presented
> code will not compile. GCC produces an error: "binding 'const int' to 'int
> &' discards qualifiers". To overcome that issue we can introduce a
> temporary:
>
> void bar()
> {
> constexpr int tmp = get_val();
> int val = tmp;
> foo(val);
> }
>
> Problem solved, but now, we have unneeded and unwanted variable, which has
> no cost, but it's still there, in the code, takes free space. If we'd had
> constexpr-expression in a language, we could've solved our problem like
> this:
>
> void bar()
> {
> int val = constexpr (get_val());
> foo(val);
> }
>
> What constexpr-expression could do? It could force compile-time evaluation
> of an expression. If evaluation at compile-time is not possible, then we'd
> get loud failure, instead of possible run-time errors, or not matching
> expectations.
>
> So, now there is no temporaries, only what's needed, and no run-time cost,
> but, there is also one more question: "Do we need parentheses around
> expression in constexpr-expression?"
>
> int val = constexpr get_val();
>
> Without parentheses, 'constexpr' looks like a prefix to an expression, what
> I find nice, and less noisy.
>
> Coming back to 'if constexpr'; If thinking that 'constexpr' is closer to
> condition than to an 'if' is the right way to think, then we can make one
> step further and put 'constexpr' inside parentheses.
>
> if (constexpr condition) {
> ...
> }
>
> It's far from how 'static_if' or 'constexpr if' looks, but nor 'if
> constexpr' looks like them. This syntax, in my opinion, is less ambiguous in
> it's "if-ness", then 'if constexpr'.
>
> Thoughts?
>
> --
> 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/33d19c42-848a-4952-9724-26b98790742b%40isocpp.org.
--
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/CAOfiQqnigC2PMXeqepVe64t%2BRaAC_Ne840j-PEROEHncy89a-g%40mail.gmail.com.
.
Author: Andrei L <aendaerel@gmail.com>
Date: Thu, 31 Mar 2016 01:15:49 +0500
Raw View
--089e01182606d399f2052f49cfe0
Content-Type: text/plain; charset=UTF-8
2016-03-31 1:00 GMT+05:00 Richard Smith <richard@metafoo.co.uk>:
> You can do this:
>
> constexpr int &&val = get_val();
>
Correct me if I'm wrong, but type of 'val' would be 'const int &&'. I don't
see how i can use that to call 'foo(int &)'. Also
GCC produced:
prog.cc: In function 'int main()':
prog.cc:13:33: error: '<anonymous>' is not a constant expression
constexpr int &&val = get_val();
^
Clang produced:
prog.cc:13:19: error: constexpr variable 'val' must be initialized by
a constant expression
constexpr int &&val = get_val();
^ ~~~~~~~~~
prog.cc:13:19: note: reference to temporary is not a constant expression
prog.cc:13:25: note: temporary created here
constexpr int &&val = get_val();
^
--
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/CANaLnBpbEBOog%2Bc%3DK_GUJcNaWpGyiOQpTMX%3DXs7wDU93JDKWAA%40mail.gmail.com.
--089e01182606d399f2052f49cfe0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2016-03-31 1:00 GMT+05:00 Richard Smith <span dir=3D"ltr"><<a href=3D"ma=
ilto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>>=
</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=3D":l=
e" class=3D"" style=3D"overflow:hidden">You can do this:<br>
<br>
constexpr int &&val =3D get_val();</div></blockquote></div><br></di=
v><div class=3D"gmail_extra">Correct me if I'm wrong, but type of '=
val' would be 'const int &&'. I don't see how i can=
use that to call 'foo(int &)'. Also<br><br></div><div class=3D=
"gmail_extra">GCC produced:<br><pre style=3D"margin-left:40px" class=3D""><=
span style=3D"color:rgb(0,0,0)">prog.cc: In function 'int main()':
prog.cc:13:33: error: '<anonymous>' is not a constant express=
ion
constexpr int &&val =3D get_val();
^</span></pre></div><div class=3D"gmail_ex=
tra">Clang produced:<br><pre style=3D"margin-left:40px" class=3D""><span st=
yle=3D"color:rgb(0,0,0)">prog.cc:13:19: error: constexpr variable 'val&=
#39; must be initialized by a constant expression
constexpr int &&val =3D get_val();
^ ~~~~~~~~~
prog.cc:13:19: note: reference to temporary is not a constant expression
prog.cc:13:25: note: temporary created here
constexpr int &&val =3D get_val();
^</span></pre></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/CANaLnBpbEBOog%2Bc%3DK_GUJcNaWpGyiOQp=
TMX%3DXs7wDU93JDKWAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANaLnBpbEB=
Oog%2Bc%3DK_GUJcNaWpGyiOQpTMX%3DXs7wDU93JDKWAA%40mail.gmail.com</a>.<br />
--089e01182606d399f2052f49cfe0--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 30 Mar 2016 13:32:59 -0700
Raw View
On Wed, Mar 30, 2016 at 1:15 PM, Andrei L <aendaerel@gmail.com> wrote:
>
> 2016-03-31 1:00 GMT+05:00 Richard Smith <richard@metafoo.co.uk>:
>>
>> You can do this:
>>
>> constexpr int &&val = get_val();
>
>
> Correct me if I'm wrong, but type of 'val' would be 'const int &&'. I don't
> see how i can use that to call 'foo(int &)'.
You're wrong :) The type of 'val' would be 'int &&'.
> Also
>
> GCC produced:
>
> prog.cc: In function 'int main()':
> prog.cc:13:33: error: '<anonymous>' is not a constant expression
> constexpr int &&val = get_val();
> ^
>
> Clang produced:
>
> prog.cc:13:19: error: constexpr variable 'val' must be initialized by a
> constant expression
> constexpr int &&val = get_val();
> ^ ~~~~~~~~~
> prog.cc:13:19: note: reference to temporary is not a constant expression
> prog.cc:13:25: note: temporary created here
> constexpr int &&val = get_val();
> ^
Ah right, you also need to make it static. Sorry about that :)
--
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/CAOfiQqnMhtKPcy3sCKeV%2BfAfZmdKsiKaHjJksGYzhbrtKSykeA%40mail.gmail.com.
.
Author: Andrei L <aendaerel@gmail.com>
Date: Thu, 31 Mar 2016 04:54:23 +0500
Raw View
--089e013cb8027ace77052f4cdd33
Content-Type: text/plain; charset=UTF-8
2016-03-31 1:32 GMT+05:00 Richard Smith <richard@metafoo.co.uk>:
> The type of 'val' would be 'int &&'
Oh. Is 'constexpr' applies 'const' to whole thing? i.e. 'int && const'?
Ah right, you also need to make it static. Sorry about that :)
>
Heh :)
After jumping through 'static' and '&&', we got what we wanted, but not
quite. We turned simple local variable into static one.
Don't get me wrong. I don't think that using temporary variable is bad. For
example, if we have 'a(b(c(d(e(f(g()))))))', then, to make that readable,
we can make bunch of temporaries to store intermediate results and use them
in next consequential calls (UFCS could help us here). Temporary is just an
annoyance and it would be nice to get rid of 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/CANaLnBo6u%3Dyxf_%3DtB3AeOOrT%3DU-Q5Qe59nW85WZyHVXb5TV2FQ%40mail.gmail.com.
--089e013cb8027ace77052f4cdd33
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2016-03-31 1:32 GMT+05:00 Richard Smith <span dir=3D"ltr"><<a href=3D"ma=
ilto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>>=
</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The type of &=
#39;val' would be 'int &&'</blockquote></div><br></div>=
<div class=3D"gmail_extra">Oh. Is 'constexpr' applies 'const=
9; to whole thing? i.e. 'int && const'?<br><br><blockquote =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex" class=3D"gmail_quote">Ah right, you also need to make it st=
atic. Sorry about that :)<br></blockquote><div><br></div><div>Heh :)<br><br=
></div><div>After jumping through 'static' and '&&'=
, we got what we wanted, but not quite. We turned simple local variable int=
o static one.<br><br></div><div>Don't get me wrong. I don't think t=
hat using temporary variable is bad. For example, if we have 'a(b(c(d(e=
(f(g()))))))', then, to make that readable, we can make bunch of tempor=
aries to store intermediate results and use them in next consequential call=
s (UFCS could help us here). Temporary is just an annoyance and it would be=
nice to get rid of it.<br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANaLnBo6u%3Dyxf_%3DtB3AeOOrT%3DU-Q5Q=
e59nW85WZyHVXb5TV2FQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANaLnBo6u%=
3Dyxf_%3DtB3AeOOrT%3DU-Q5Qe59nW85WZyHVXb5TV2FQ%40mail.gmail.com</a>.<br />
--089e013cb8027ace77052f4cdd33--
.
Author: "'Johannes Schaub' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 31 Mar 2016 17:23:51 +0200
Raw View
--001a1140219e88eed4052f59d9bd
Content-Type: text/plain; charset=UTF-8
I think of "if constexpr .. else .." as
if .. always holds then .. otherwise if it never holds.. otherwise error
Note that the "otherwise if" corresponds to "else". Not "else if" which
would be "else if it never holds then if". I.e the "constexpr" determines a
dependency mode for "if" which affects both branches.
Therefore the "constexpr" for else is not implied for me. Now if you put
the "constexpr" into the condition, then that reads to me as
if .. neither always nor never holds then error otherwise whenever it
holds .. otherwise whenever it doesn't hold...
Here, the "constexpr" just validates that we know of the constness similar
to puttting the condition into "sizeof(char[1+cond])". But it doesn't
affect the dependency mode: It's still checked with the dynamic control
flow.
Am 30.03.2016 05:51 schrieb "Andrei L" <aendaerel@gmail.com>:
>
> Hello.
>
> At the last committee meeting, there was made a decision to change syntax
from 'constexpr if' to 'if constexpr', and while this decision has it's
reasons, there is minor issue with it. It is somewhat unclear, what 'if
constexpr' is means. I understand what it means but still, I feel urge to
read 'if constexpr ... else ....' as: "if constexpr, then do this, if not
constexpr, do that." This issue can be solved, if you think about
'constexpr', as part of condition, as a requirement that condition must be
constexpr, but syntactically, it is placed outside parentheses, closer to
an 'if', than to condition. If we'd have something like 'constexpr (
expression )' in the language, then that form of 'if' could've be explained
as 'if (constexpr (condition))', and we could say that since parentheses
around constexpr-condition are redundant, we are allowed to drop them.
>
> That made me think: "Why can't we have that constexpr-expression?" Given
that there is desire to be able to require compile-time evaluation, I find
it quite strange that we don't have something like that already.
>
> Consider:
>
> constexpr int get_val();
>
> void foo(int &);
> void bar()
> {
> constexpr int val = get_val();
> foo(val);
> }
>
> So, we have constexpr functions in the language, and they are not
required to be called at compile time. To make sure, that we don't pay cost
at run-time for what we can do at compile-time, we assign result of a
function call to a constexpr variable. But, constexpr implies const, so
presented code will not compile. GCC produces an error: "binding 'const
int' to 'int &' discards qualifiers". To overcome that issue we can
introduce a temporary:
>
> void bar()
> {
> constexpr int tmp = get_val();
> int val = tmp;
> foo(val);
> }
>
> Problem solved, but now, we have unneeded and unwanted variable, which
has no cost, but it's still there, in the code, takes free space. If we'd
had constexpr-expression in a language, we could've solved our problem like
this:
>
> void bar()
> {
> int val = constexpr (get_val());
> foo(val);
> }
>
> What constexpr-expression could do? It could force compile-time
evaluation of an expression. If evaluation at compile-time is not possible,
then we'd get loud failure, instead of possible run-time errors, or not
matching expectations.
>
> So, now there is no temporaries, only what's needed, and no run-time
cost, but, there is also one more question: "Do we need parentheses around
expression in constexpr-expression?"
>
> int val = constexpr get_val();
>
> Without parentheses, 'constexpr' looks like a prefix to an expression,
what I find nice, and less noisy.
>
> Coming back to 'if constexpr'; If thinking that 'constexpr' is closer to
condition than to an 'if' is the right way to think, then we can make one
step further and put 'constexpr' inside parentheses.
>
> if (constexpr condition) {
> ...
> }
>
> It's far from how 'static_if' or 'constexpr if' looks, but nor 'if
constexpr' looks like them. This syntax, in my opinion, is less ambiguous
in it's "if-ness", then 'if constexpr'.
>
> Thoughts?
>
--
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/CANu6V4XJSTy3SGQUFXRT66-3XwoqcT5KL_%3DcuedyZKRu%2Bm-i%3Dg%40mail.gmail.com.
--001a1140219e88eed4052f59d9bd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I think of "if constexpr .. else .." as</p>
<p dir=3D"ltr">=C2=A0 if .. always holds then .. otherwise if it never hold=
s.. otherwise error</p>
<p dir=3D"ltr">Note that the "otherwise if" corresponds to "=
else". Not "else if" which would be "else if it never h=
olds then if". I.e the "constexpr" determines a dependency m=
ode for "if" which affects both branches.</p>
<p dir=3D"ltr">Therefore the "constexpr" for else is not implied =
for me. Now if you put the "constexpr" into the condition, then t=
hat reads to me as</p>
<p dir=3D"ltr">=C2=A0=C2=A0 if .. neither always nor never holds then error=
otherwise whenever it holds .. otherwise whenever it doesn't hold...</=
p>
<p dir=3D"ltr">Here, the "constexpr" just validates that we know =
of the constness similar to puttting the condition into "sizeof(char[1=
+cond])". But it doesn't affect the dependency mode: It's stil=
l checked with the dynamic control flow.</p>
<p dir=3D"ltr">Am 30.03.2016 05:51 schrieb "Andrei L" <<a href=
=3D"mailto:aendaerel@gmail.com">aendaerel@gmail.com</a>>:<br>
><br>
> Hello.<br>
><br>
> At the last committee meeting, there was made a decision to change syn=
tax from 'constexpr if' to 'if constexpr', and while this d=
ecision has it's reasons, there is minor issue with it. It is somewhat =
unclear, what 'if constexpr' is means. I understand what it means b=
ut still, I feel urge to read 'if constexpr ... else ....' as: &quo=
t;if constexpr, then do this, if not constexpr, do that." This issue c=
an be solved, if you think about 'constexpr', as part of condition,=
as a requirement that condition must be constexpr, but syntactically, it i=
s placed outside parentheses, closer to an 'if', than to condition.=
If we'd have something like 'constexpr ( expression )' in the =
language, then that form of 'if' could've be explained as '=
if (constexpr (condition))', and we could say that since parentheses ar=
ound constexpr-condition are redundant, we are allowed to drop them.<br>
><br>
> That made me think: "Why can't we have that constexpr-express=
ion?" Given that there is desire to be able to require compile-time ev=
aluation, I find it quite strange that we don't have something like tha=
t already.<br>
><br>
> Consider:<br>
><br>
> constexpr int get_val();<br>
><br>
> void foo(int &);<br>
> void bar()<br>
> {<br>
> =C2=A0 constexpr int val =3D get_val();<br>
> =C2=A0 foo(val);<br>
> }<br>
><br>
> So, we have constexpr functions in the language, and they are not requ=
ired to be called at compile time. To make sure, that we don't pay cost=
at run-time for what we can do at compile-time, we assign result of a func=
tion call to a constexpr variable. But, constexpr implies const, so present=
ed code will not compile. GCC produces an error: "binding 'const i=
nt' to 'int &' discards qualifiers". To overcome that =
issue we can introduce a temporary:<br>
><br>
> void bar()<br>
> {<br>
> =C2=A0 constexpr int tmp =3D get_val();<br>
> =C2=A0 int val =3D tmp;<br>
> =C2=A0 foo(val);<br>
> }<br>
><br>
> Problem solved, but now, we have unneeded and unwanted variable, which=
has no cost, but it's still there, in the code, takes free space. If w=
e'd had constexpr-expression in a language, we could've solved our =
problem like this:<br>
><br>
> void bar()<br>
> {<br>
> =C2=A0 int val =3D constexpr (get_val());<br>
> =C2=A0 foo(val);<br>
> }<br>
><br>
> What constexpr-expression could do? It could force compile-time evalua=
tion of an expression. If evaluation at compile-time is not possible, then =
we'd get loud failure, instead of possible run-time errors, or not matc=
hing expectations.<br>
><br>
> So, now there is no temporaries, only what's needed, and no run-ti=
me cost, but, there is also one more question: "Do we need parentheses=
around expression in constexpr-expression?"<br>
><br>
> int val =3D constexpr get_val();<br>
><br>
> Without parentheses, 'constexpr' looks like a prefix to an exp=
ression, what I find nice, and less noisy.<br>
><br>
> Coming back to 'if constexpr'; If thinking that 'constexpr=
' is closer to condition than to an 'if' is the right way to th=
ink, then we can make one step further and put 'constexpr' inside p=
arentheses.<br>
><br>
> if (constexpr condition) {<br>
> =C2=A0 ...<br>
> }<br>
><br>
> It's far from how 'static_if' or 'constexpr if' lo=
oks, but nor 'if constexpr' looks like them. This syntax, in my opi=
nion, is less ambiguous in it's "if-ness", then 'if const=
expr'.<br>
><br>
> Thoughts?<br>
></p>
<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/CANu6V4XJSTy3SGQUFXRT66-3XwoqcT5KL_%3=
DcuedyZKRu%2Bm-i%3Dg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4XJST=
y3SGQUFXRT66-3XwoqcT5KL_%3DcuedyZKRu%2Bm-i%3Dg%40mail.gmail.com</a>.<br />
--001a1140219e88eed4052f59d9bd--
.
Author: "'Johannes Schaub' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 31 Mar 2016 17:27:33 +0200
Raw View
--001a11410b30bf5a71052f59e613
Content-Type: text/plain; charset=UTF-8
Am 31.03.2016 01:54 schrieb "Andrei L" <aendaerel@gmail.com>:
>
>
> 2016-03-31 1:32 GMT+05:00 Richard Smith <richard@metafoo.co.uk>:
>>
>> The type of 'val' would be 'int &&'
>
>
> Oh. Is 'constexpr' applies 'const' to whole thing? i.e. 'int && const'?
>
I think it does that only for declarations of objects (i.e for object
declarations with nonreference types).
--
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/CANu6V4Vyku2rbYLTtFmdcMLKzy2AdO8mTT_D5g_rf1sS9DN8yA%40mail.gmail.com.
--001a11410b30bf5a71052f59e613
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Am 31.03.2016 01:54 schrieb "Andrei L" <<a href=3D"mailto:aend=
aerel@gmail.com">aendaerel@gmail.com</a>>:<br>
><br>
><br>
> 2016-03-31 1:32 GMT+05:00 Richard Smith <<a href=3D"mailto:richard@=
metafoo.co.uk">richard@metafoo.co.uk</a>>:<br>
>><br>
>> The type of 'val' would be 'int &&'<br>
><br>
><br>
> Oh. Is 'constexpr' applies 'const' to whole thing? i.e=
.. 'int && const'?<br>
></p>
<p dir=3D"ltr">I think it does that only for declarations of objects (i.e f=
or object declarations with nonreference types).</p>
<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/CANu6V4Vyku2rbYLTtFmdcMLKzy2AdO8mTT_D=
5g_rf1sS9DN8yA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4Vyku2rbYLT=
tFmdcMLKzy2AdO8mTT_D5g_rf1sS9DN8yA%40mail.gmail.com</a>.<br />
--001a11410b30bf5a71052f59e613--
.
Author: Paul Fultz II <pfultz28@gmail.com>
Date: Mon, 4 Apr 2016 13:52:18 -0700 (PDT)
Raw View
------=_Part_164_2027148108.1459803138563
Content-Type: multipart/alternative;
boundary="----=_Part_165_1245322387.1459803138563"
------=_Part_165_1245322387.1459803138563
Content-Type: text/plain; charset=UTF-8
On Wednesday, March 30, 2016 at 6:54:25 PM UTC-5, Andrei L wrote:
>
>
> 2016-03-31 1:32 GMT+05:00 Richard Smith <ric...@metafoo.co.uk
> <javascript:>>:
>
>> The type of 'val' would be 'int &&'
>
>
> Oh. Is 'constexpr' applies 'const' to whole thing? i.e. 'int && const'?
>
> Ah right, you also need to make it static. Sorry about that :)
>>
>
> Heh :)
>
> After jumping through 'static' and '&&', we got what we wanted, but not
> quite. We turned simple local variable into static one.
>
That is exactly what `constexpr if` is, it is `static_if` because the value
must be known statically. For example, this won't work:
template<class T, class U>
constexpr auto pick(bool b, T x, U y)
{
if constexpr(b) return x;
else return y;
}
Even though the variable `b` can be know at compile-time, this won't work
because the function returns a different type depending on whether the
boolean is true or not. This can be fixed by using a static boolean
instead, like this:
template<bool B, class T, class U>
constexpr auto pick(T x, U y)
{
if constexpr(B) return x;
else return y;
}
Or use an integral constant, which stores its value statically as well:
template<class IntegralConstant, class T, class U>
constexpr auto pick(IntegralConstant b, T x, U y)
{
if constexpr(b) return x;
else return y;
}
Ultimately, I think the use of `constexpr if` is a poor term to use, causes
confusion, and does not accurately describe what is required(that is the
value must be known at compile-time *and* static). No doubt, `static_if`
would better describe it and would be more consistent with the rest of the
language(such as `static_assert`), however, there seems to be political
issues with that name. Perhaps a better option could be to use something
like angle brackets, since template parameters require compile-time values
that are static:
template<bool B, class T, class U>
constexpr auto pick(T x, U y)
{
if<B>
{
return x;
}
else
{
return y;
}
}
Paul
--
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/133d308f-621c-4f7d-abd5-b794aacb7f51%40isocpp.org.
------=_Part_165_1245322387.1459803138563
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, March 30, 2016 at 6:54:25 PM UTC-5, =
Andrei L 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=
"><div><br><div class=3D"gmail_quote">2016-03-31 1:32 GMT+05:00 Richard Smi=
th <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"D6mPbm0pDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">ric...@metafoo.co.uk</a>></span>:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">The type of 'val' would be '=
int &&'</blockquote></div><br></div><div>Oh. Is 'constexpr&=
#39; applies 'const' to whole thing? i.e. 'int && const=
'?<br><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">Ah right, y=
ou also need to make it static. Sorry about that :)<br></blockquote><div><b=
r></div><div>Heh :)<br><br></div><div>After jumping through 'static'=
; and '&&', we got what we wanted, but not quite. We turned=
simple local variable into static one.<br></div></div></div></blockquote><=
div><br>That is exactly what `constexpr if` is, it is `static_if` because t=
he value must be known statically. For example, this won't work:<br><br=
>template<class T, class U><br>constexpr auto pick(bool b, T x, U y)<=
br>{<br>=C2=A0=C2=A0=C2=A0 if constexpr(b) return x;<br>=C2=A0=C2=A0=C2=A0 =
else return y;<br>}<br><br>Even though the variable `b` can be know at comp=
ile-time, this won't work because the function returns a different type=
depending on whether the boolean is true or not. This can be fixed by usin=
g a static boolean instead, like this:<br><br>template<bool B, class T, =
class U><br>constexpr auto pick(T x, U y)<br>{<br>=C2=A0=C2=A0=C2=A0 if =
constexpr(B) return x;<br>=C2=A0=C2=A0=C2=A0 else return y;<br>}<br><br>Or =
use an integral constant, which stores its value statically as well:<br><br=
>template<class IntegralConstant, class T, class U><br>constexpr auto=
pick(IntegralConstant b, T x, U y)<br>{<br>=C2=A0=C2=A0=C2=A0 if constexpr=
(b) return x;<br>=C2=A0=C2=A0=C2=A0 else return y;<br>}<br><br>Ultimately, =
I think the use of `constexpr if` is a poor term to use, causes confusion, =
and does not accurately describe what is required(that is the value must be=
known at compile-time *and* static). No doubt, `static_if` would better de=
scribe it and would be more consistent with the rest of the language(such a=
s `static_assert`), however, there seems to be political issues with that n=
ame. Perhaps a better option could be to use something like angle brackets,=
since template parameters require compile-time values that are static:<br>=
<br>template<bool B, class T, class U><br>constexpr auto pick(T x, U =
y)<br>{<br>=C2=A0=C2=A0=C2=A0 if<B><br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return x;<br>=C2=A0=C2=A0=C2=A0 }<br>=
=C2=A0=C2=A0=C2=A0 else<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 return y;<br>=C2=A0=C2=A0=C2=A0 }<br>}<br><br>Paul<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/133d308f-621c-4f7d-abd5-b794aacb7f51%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/133d308f-621c-4f7d-abd5-b794aacb7f51=
%40isocpp.org</a>.<br />
------=_Part_165_1245322387.1459803138563--
------=_Part_164_2027148108.1459803138563--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 5 Apr 2016 00:07:20 +0300
Raw View
On 4 April 2016 at 23:52, Paul Fultz II <pfultz28@gmail.com> wrote:
> Ultimately, I think the use of `constexpr if` is a poor term to use, causes
> confusion, and does not accurately describe what is required(that is the
> value must be known at compile-time *and* static). No doubt, `static_if`
> would better describe it and would be more consistent with the rest of the
> language(such as `static_assert`), however, there seems to be political
> issues with that name. Perhaps a better option could be to use something
> like angle brackets, since template parameters require compile-time values
> that are static:
For what it's worth, I decided against keeping calling it static_if (as I did
in http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4461.html), because
it's not the static if e.g. D has; a constexpr if has a much narrower
focus and can't
do all the bells and whistles D's static if can. My papers explain
why, but tl;dr is that
it turned out to be very hard to have such a control statement outside
a block scope,
and the issue of whether it should or should not establish a new scope
wasn't entirely
understood in Kona 2012, but became much better understood since.
I don't see the problem with "if constexpr". Sure, you can think of it
as "the condition
must be compile-time and static", I think of it as "the condition must
be a constant expression
convertible to bool". A "static" doesn't seem to describe that any
better, quite the opposite.
--
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/CAFk2RUYD3m18HSW5MLx60xGoRfDwSPhT4A1ngmVkX%3DFXci%2B2hA%40mail.gmail.com.
.
Author: Paul Fultz II <pfultz28@gmail.com>
Date: Mon, 4 Apr 2016 18:35:22 -0700 (PDT)
Raw View
------=_Part_43_1215713578.1459820122269
Content-Type: multipart/alternative;
boundary="----=_Part_44_1464424406.1459820122269"
------=_Part_44_1464424406.1459820122269
Content-Type: text/plain; charset=UTF-8
On Monday, April 4, 2016 at 4:07:21 PM UTC-5, Ville Voutilainen wrote:
>
> On 4 April 2016 at 23:52, Paul Fultz II <pful...@gmail.com <javascript:>>
> wrote:
> > Ultimately, I think the use of `constexpr if` is a poor term to use,
> causes
> > confusion, and does not accurately describe what is required(that is the
> > value must be known at compile-time *and* static). No doubt, `static_if`
> > would better describe it and would be more consistent with the rest of
> the
> > language(such as `static_assert`), however, there seems to be political
> > issues with that name. Perhaps a better option could be to use something
> > like angle brackets, since template parameters require compile-time
> values
> > that are static:
>
>
> For what it's worth, I decided against keeping calling it static_if (as I
> did
> in http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4461.html),
> because
> it's not the static if e.g. D has; a constexpr if has a much narrower
> focus and can't
> do all the bells and whistles D's static if can. My papers explain
> why, but tl;dr is that
> it turned out to be very hard to have such a control statement outside
> a block scope,
> and the issue of whether it should or should not establish a new scope
> wasn't entirely
> understood in Kona 2012, but became much better understood since.
>
Most don't expect static_if to work like it does in D. When most people
talk about emulating static_if in C++, it works like the so called
`constexpr if` thats being proposed.
>
> I don't see the problem with "if constexpr".
>
Sure, you can think of it
> as "the condition
> must be compile-time and static",
I think of it as "the condition must
> be a constant expression
> convertible to bool".
Should `constexpr` always imply `static`, then? For example, this is not
valid because it is not a constant expression:
constexpr void foo(bool b)
{
constexpr bool r = b;
}
However, using an integral constant it is:
template<class IntegralConstant>
constexpr void foo(IntegralConstant b)
{
constexpr bool r = b;
}
However, the example Richard Smith gave required `static`. Perhaps to make
it clearer, `constexpr` variables should always imply `static`. This way
`constexpr(...)` is like declaring an anonymous `constexpr` variable(which
of course would mean its `static` as well). Would it ever make sense to
have `constexpr` variables to be non-static?
> A "static" doesn't seem to describe that any
> better, quite the opposite.
>
It describes it the same way as static_assert.
--
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/a9868e6b-6570-417c-bca2-94f64b57f798%40isocpp.org.
------=_Part_44_1464424406.1459820122269
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, April 4, 2016 at 4:07:21 PM UTC-5, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 4 April=
2016 at 23:52, Paul Fultz II <<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"RURW7-hxAQAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">pful...@gmail.com</a>> wrote:
<br>> Ultimately, I think the use of `constexpr if` is a poor term to us=
e, causes
<br>> confusion, and does not accurately describe what is required(that =
is the
<br>> value must be known at compile-time *and* static). No doubt, `stat=
ic_if`
<br>> would better describe it and would be more consistent with the res=
t of the
<br>> language(such as `static_assert`), however, there seems to be poli=
tical
<br>> issues with that name. Perhaps a better option could be to use som=
ething
<br>> like angle brackets, since template parameters require compile-tim=
e values
<br>> that are static:
<br>
<br>
<br>For what it's worth, I decided against keeping calling it static_if=
(as I did
<br>in <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4461=
..html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'h=
ttp://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21=
%2Fdocs%2Fpapers%2F2015%2Fn4461.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEaw=
WB0w0tIYosOF5iyesDVFVsT4g';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%=
2Fdocs%2Fpapers%2F2015%2Fn4461.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEawW=
B0w0tIYosOF5iyesDVFVsT4g';return true;">http://open-std.org/JTC1/SC22/<=
wbr>WG21/docs/papers/2015/n4461.<wbr>html</a>), because
<br>it's not the static if e.g. D has; a constexpr if has a much narrow=
er
<br>focus and can't
<br>do all the bells and whistles D's static if can. My papers explain
<br>why, but tl;dr is that
<br>it turned out to be very hard to have such a control statement outside
<br>a block scope,
<br>and the issue of whether it should or should not establish a new scope
<br>wasn't entirely
<br>understood in Kona 2012, but became much better understood since.
<br></blockquote><div><br>Most don't expect static_if to work like it d=
oes in D. When most people talk about emulating static_if in C++, it works =
like the so called `constexpr if` thats being proposed.<br>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">
<br>I don't see the problem with "if constexpr". <br></blockq=
uote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">Sure, you can think of it
<br>as "the condition
<br>must be compile-time and static",=C2=A0</blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">I think of it as "the condition must
<br>be a constant expression
<br>convertible to bool".=C2=A0</blockquote><div><br>Should `constexpr=
` always imply `static`, then? For example, this is not valid because it is=
not a constant expression:<br><br>constexpr void foo(bool b)<br>{<br>=C2=
=A0=C2=A0=C2=A0 constexpr bool r =3D b;<br>}<br><br>However, using an integ=
ral constant it is:<br><br>template<class IntegralConstant><br>conste=
xpr void foo(IntegralConstant b)<br>{<br>=C2=A0=C2=A0=C2=A0 constexpr bool =
r =3D b;<br>}<br><br>However, the example Richard Smith gave required `stat=
ic`. Perhaps to make it clearer, `constexpr` variables should always imply =
`static`. This way `constexpr(...)` is like declaring an anonymous `constex=
pr` variable(which of course would mean its `static` as well). Would it eve=
r make sense to have `constexpr` variables to be non-static?<br>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">A "static" doesn=
9;t seem to describe that any
<br>better, quite the opposite.
<br></blockquote><div><br>It describes it the same way as static_assert.=C2=
=A0 <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/a9868e6b-6570-417c-bca2-94f64b57f798%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a9868e6b-6570-417c-bca2-94f64b57f798=
%40isocpp.org</a>.<br />
------=_Part_44_1464424406.1459820122269--
------=_Part_43_1215713578.1459820122269--
.
Author: Andrei L <aendaerel@gmail.com>
Date: Tue, 5 Apr 2016 15:05:33 +0500
Raw View
--001a11c173d46992e6052fb9fcb4
Content-Type: text/plain; charset=UTF-8
2016-04-05 6:35 GMT+05:00 Paul Fultz II <pfultz28@gmail.com>:
However, the example Richard Smith gave required `static`.
>
The goal was to get non-const, non-static local variable initialized by
result of constexpr function called at compile-time.
Perhaps to make it clearer, `constexpr` variables should always imply
> `static`. <..> Would it ever make sense to have `constexpr` variables to be
> non-static?
I fail to see what compile-time constant has to do with linkage or storage
duration. Are you mixing meaning of `constexpr` and `static` in the
language and meaning of `static` outside the language?
This way `constexpr(...)` is like declaring an anonymous `constexpr`
> variable(which of course would mean its `static` as well).
I don't think it should declare or act like it's declaring something. I
think it should be just an assertion that something is going to be
evaluated at compile-time, a strong guarantee.
--
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/CANaLnBrF6PSa8Kafch_KfJCC0VMg-q7655A9ZsO0WrvBeQQYCQ%40mail.gmail.com.
--001a11c173d46992e6052fb9fcb4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2016-04-05 6:35 GMT+05:00 Paul Fultz II <span dir=3D"ltr"><<a href=3D"ma=
ilto:pfultz28@gmail.com" target=3D"_blank">pfultz28@gmail.com</a>></span=
>:<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">However, the ex=
ample Richard Smith gave required `static`.<br></blockquote></div><br></div=
><div class=3D"gmail_extra">The goal was to get non-const, non-static local=
variable initialized by result of constexpr function called at compile-tim=
e.<br><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">Perhaps to make=
it clearer, `constexpr` variables should always imply `static`. <..>=
Would it ever make sense to have `constexpr` variables to be non-static?</=
blockquote><br></div><div class=3D"gmail_extra">I fail to see what compile-=
time constant has to do with linkage or storage duration. Are you mixing me=
aning of `constexpr` and `static` in the language and meaning of `static` o=
utside the language?<br><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quot=
e">This way `constexpr(...)` is like declaring an anonymous `constexpr` var=
iable(which of course would mean its `static` as well).</blockquote><br></d=
iv><div class=3D"gmail_extra">I don't think it should declare or act li=
ke it's declaring something. I think it should be just an assertion tha=
t something is going to be evaluated at compile-time, a strong guarantee.<b=
r></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/CANaLnBrF6PSa8Kafch_KfJCC0VMg-q7655A9=
ZsO0WrvBeQQYCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANaLnBrF6PSa8Kaf=
ch_KfJCC0VMg-q7655A9ZsO0WrvBeQQYCQ%40mail.gmail.com</a>.<br />
--001a11c173d46992e6052fb9fcb4--
.
Author: Paul Fultz II <pfultz28@gmail.com>
Date: Tue, 5 Apr 2016 09:30:46 -0700 (PDT)
Raw View
------=_Part_349_1657948565.1459873846629
Content-Type: multipart/alternative;
boundary="----=_Part_350_808521112.1459873846629"
------=_Part_350_808521112.1459873846629
Content-Type: text/plain; charset=UTF-8
On Tuesday, April 5, 2016 at 5:05:35 AM UTC-5, Andrei L wrote:
>
>
> 2016-04-05 6:35 GMT+05:00 Paul Fultz II <pful...@gmail.com <javascript:>>:
>
> However, the example Richard Smith gave required `static`.
>>
>
> The goal was to get non-const, non-static local variable initialized by
> result of constexpr function called at compile-time.
>
A `constexpr` variable or expression can be used directly in an array or
template parameter, so it must be static. Otherwise, why not use a local
variable in a constexpr function or even a template function?
>
> Perhaps to make it clearer, `constexpr` variables should always imply
>> `static`. <..> Would it ever make sense to have `constexpr` variables to be
>> non-static?
>
>
> I fail to see what compile-time constant has to do with linkage or storage
> duration. Are you mixing meaning of `constexpr` and `static` in the
> language and meaning of `static` outside the language?
>
Like I said, constexpr variables require static storage duration. Instead
of requiring `static constexpr x = ...;`, static duration should be
implicit with `constexpr` variables. So then the `static` keyword could be
omitted and it can be written like: `constexpr x = ...;`. This would make
it consistent with the `constexpr(...)` construct used with `if
constexpr(...)` since that requires static duration as well.
>
> This way `constexpr(...)` is like declaring an anonymous `constexpr`
>> variable(which of course would mean its `static` as well).
>
>
> I don't think it should declare or act like it's declaring something. I
> think it should be just an assertion that something is going to be
> evaluated at compile-time, a strong guarantee.
>
But for `constexpr(...)` to assert compile-time evaluation it should be
both consistent with `if constexpr(...)` and `constexpr` variables, which
both require static storage duration. So it makes sense to describe it as
declaring a `constexpr` variable.
A better way to say it, would be that `constexpr(...)` is equivalent to
`[]{ static constexpr auto&& x = ...; return x; }`. Even more so, if
`constexpr` implies `static`, it could be written just as: `[]{ constexpr
auto&& x = ...; return x; }`, which I think it makes it more consistent.
Plus, I don't think it would ever makes sense to have a non-static
`constexpr` variables.
Paul
--
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/c16522fb-7935-42af-bb11-96c10beef5f1%40isocpp.org.
------=_Part_350_808521112.1459873846629
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, April 5, 2016 at 5:05:35 AM UTC-5, And=
rei L wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><br><div class=3D"gmail_quote">2016-04-05 6:35 GMT+05:00 Paul Fultz II =
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"jgONs2CcAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;javascript:';return true;" onclick=3D"this.href=3D'javascript:=
9;;return true;">pful...@gmail.com</a>></span>:<br><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">However, the example Richard Smith gave re=
quired `static`.<br></blockquote></div><br></div><div>The goal was to get n=
on-const, non-static local variable initialized by result of constexpr func=
tion called at compile-time.<br></div></div></blockquote><div><br>A `conste=
xpr` variable or expression can be used directly in an array or template pa=
rameter, so it must be static. Otherwise, why not use a local variable in a=
constexpr function or even a template function?<br>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br><blockquote sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex" class=3D"gmail_quote">Perhaps to make it clearer, `constexpr` =
variables should always imply `static`. <..> Would it ever make sense=
to have `constexpr` variables to be non-static?</blockquote><br></div><div=
>I fail to see what compile-time constant has to do with linkage or storage=
duration. Are you mixing meaning of `constexpr` and `static` in the langua=
ge and meaning of `static` outside the language?<br></div></div></blockquot=
e><div><br>Like I said, constexpr variables require static storage duration=
.. Instead of requiring `static constexpr x =3D ...;`, static duration shoul=
d be implicit with `constexpr` variables. So then the `static` keyword coul=
d be omitted and it can be written like: `constexpr x =3D ...;`. This would=
make it consistent with the `constexpr(...)` construct used with `if const=
expr(...)` since that requires static duration as well.<br>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br><blockqu=
ote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex" class=3D"gmail_quote">This way `constexpr(...)` is like=
declaring an anonymous `constexpr` variable(which of course would mean its=
`static` as well).</blockquote><br></div><div>I don't think it should =
declare or act like it's declaring something. I think it should be just=
an assertion that something is going to be evaluated at compile-time, a st=
rong guarantee.<br></div></div></blockquote><div><br>But for `constexpr(...=
)` to assert compile-time evaluation it should be both consistent with `if =
constexpr(...)` and `constexpr` variables, which both require static storag=
e duration. So it makes sense to describe it as declaring a `constexpr` var=
iable. <br><br>A better way to say it, would be that `constexpr(...)` is eq=
uivalent to `[]{ static constexpr auto&& x =3D ...; return x; }`. E=
ven more so, if `constexpr` implies `static`, it could be written just as: =
`[]{ constexpr auto&& x =3D ...; return x; }`, which I think it mak=
es it more consistent. Plus, I don't think it would ever makes sense to=
have a non-static `constexpr` variables.<br><br>Paul<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/c16522fb-7935-42af-bb11-96c10beef5f1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c16522fb-7935-42af-bb11-96c10beef5f1=
%40isocpp.org</a>.<br />
------=_Part_350_808521112.1459873846629--
------=_Part_349_1657948565.1459873846629--
.
Author: Andrei L <aendaerel@gmail.com>
Date: Tue, 5 Apr 2016 22:22:41 +0500
Raw View
--e89a8fb1ec1eafebd8052fc01757
Content-Type: text/plain; charset=UTF-8
2016-04-05 21:30 GMT+05:00 Paul Fultz II <pfultz28@gmail.com>:
> A `constexpr` variable or expression can be used directly in an array or
> template parameter, so it must be static.
Ah, i get it.
There are static variables. There are static constants. `static int val` is
a static variable. `constexpr int val` is a static constant. `static` here
`static` there, but those two are different. One changes storage duration,
other one implied by definition. `constexpr` is already static, but in
different sense.
--
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/CANaLnBrW8xO0-pR8q1aTrk7YqJ_XTpFzLwCspUtOwEOHL%2BRNKA%40mail.gmail.com.
--e89a8fb1ec1eafebd8052fc01757
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">2016-04-05 21:30 GMT+05:00 Paul Fultz II <span dir=3D"ltr"><<a=
href=3D"mailto:pfultz28@gmail.com" target=3D"_blank">pfultz28@gmail.com</a=
>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">A `constexpr` variable or e=
xpression can be used directly in an array or template parameter, so it mus=
t be static.</blockquote></div><br></div>Ah, i get it.<br><br>There are sta=
tic variables. There are static constants. `static int val` is a static var=
iable. `constexpr int val` is a static constant. `static` here `static` the=
re, but those two are different. One changes storage duration, other one im=
plied by definition. `constexpr` is already static, but in different sense.=
<br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANaLnBrW8xO0-pR8q1aTrk7YqJ_XTpFzLwCs=
pUtOwEOHL%2BRNKA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANaLnBrW8xO0-p=
R8q1aTrk7YqJ_XTpFzLwCspUtOwEOHL%2BRNKA%40mail.gmail.com</a>.<br />
--e89a8fb1ec1eafebd8052fc01757--
.