Topic: constexpr! and reduced code reusability.
Author: picppstandard@gmail.com
Date: Mon, 6 Aug 2018 05:15:58 -0700 (PDT)
Raw View
------=_Part_1398_85119335.1533557758260
Content-Type: multipart/alternative;
boundary="----=_Part_1399_1089661065.1533557758260"
------=_Part_1399_1089661065.1533557758260
Content-Type: text/plain; charset="UTF-8"
Hello,
Referring to the p1073r1 I was thinking about whether there makes sense in
reducing resuability of code in order to be sure to execute the code in
compile-time.
This seems to not be an issue at all, when there is constexpr! and
non-constexpr! function defined, because we can provide optimized version
of the code for runtime and
compile-time version for compile-time context.
I guess there still might be a use case of executing constexpr! function
when it's non-constexpr! twin is not defined at all.
For this reason I was thinking about the other approach on enforcing
compile-time execution, which would be present in calling syntax.
So with some example syntax:
constexpr(true) int foo(int);
constexpr(false) int foo(int); // optimized version for nonconstexpr
contexts. MUST be present if constexpr(true) version is present for the
sake of symmetry
or
constexpr void bar(int); //casual constexpr function
,so
foo(); // in constexpr contexts it's compile-time call in non-constexprs
contexts it's call to optimized version of function.
constexpr foo(); // in constexpr contexts it's compile-time call in
non-constexprs contexts it's ill formed.
bar(); // casual call according to the current C++ spec.
constexpr bar(); // in constexpr contexts it's compile-time call in
non-constexprs contexts it's ill formed.
What do you think about it? Do you find this useful to not forbid calling
constexpr! functions in non-constexpr contexts?
--
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/a71eaca0-21b4-43b0-a503-650d2eb2a3d6%40isocpp.org.
------=_Part_1399_1089661065.1533557758260
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello,<br><br>Referring to the p1073r1 I was thinking abou=
t whether there makes sense in reducing resuability of code in order to be =
sure to execute the code in compile-time.<br><br>This seems to not be an is=
sue at all, when there is constexpr! and non-constexpr! function defined, b=
ecause we can provide optimized version of the code for runtime and=C2=A0<b=
r>compile-time version for compile-time context.=C2=A0<br><br>I guess there=
still might be a use case of executing constexpr! function when it's n=
on-constexpr! twin is not defined at all.<div><br></div><div>For this reaso=
n I was thinking about the other approach on enforcing compile-time executi=
on, which would be present in calling syntax.<br><br>So with some example s=
yntax:<br><br>constexpr(true) int foo(int);<br>constexpr(false) int foo(int=
); // optimized version for nonconstexpr contexts. MUST be present if const=
expr(true) version is present for the sake of symmetry<br><br>or <br><br>co=
nstexpr void bar(int); //casual constexpr function<br><br>,so<br><br>foo();=
// in constexpr contexts it's compile-time call in non-constexprs cont=
exts it's call to optimized version of function.<br>constexpr foo(); //=
in constexpr contexts it's compile-time call in non-constexprs context=
s it's ill formed.<br><br>bar(); // casual call according to the curren=
t C++ spec.<br>constexpr bar(); // in constexpr contexts it's compile-t=
ime call in non-constexprs contexts it's ill formed.<br><br>What do you=
think about it? Do you find this useful to not forbid calling constexpr! f=
unctions in non-constexpr contexts?<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a71eaca0-21b4-43b0-a503-650d2eb2a3d6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a71eaca0-21b4-43b0-a503-650d2eb2a3d6=
%40isocpp.org</a>.<br />
------=_Part_1399_1089661065.1533557758260--
------=_Part_1398_85119335.1533557758260--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 6 Aug 2018 07:47:25 -0700 (PDT)
Raw View
------=_Part_1485_1337282239.1533566845308
Content-Type: multipart/alternative;
boundary="----=_Part_1486_256279649.1533566845308"
------=_Part_1486_256279649.1533566845308
Content-Type: text/plain; charset="UTF-8"
On Monday, August 6, 2018 at 8:15:58 AM UTC-4, picpps...@gmail.com wrote:
>
> Hello,
>
> Referring to the p1073r1 I was thinking about whether there makes sense in
> reducing resuability of code in order to be sure to execute the code in
> compile-time.
>
> This seems to not be an issue at all, when there is constexpr! and
> non-constexpr! function defined, because we can provide optimized version
> of the code for runtime and
> compile-time version for compile-time context.
>
> I guess there still might be a use case of executing constexpr! function
> when it's non-constexpr! twin is not defined at all.
>
If the writer of that function did not provide a non-`constexpr` overload,
then they *do not want* that function to be called outside of constant
expression contexts. Maybe it's simply not meaningful to call it then.
Maybe there's no real point to it. Maybe the function exists solely to do
type computation, and the function therefore only needs to be "executed"
for the purpose of `decltype` statements or other similar constant
expression contexts.
Whatever the case, if a user has decided that this function should only be
executed at compile time, then we should honor that decision.
I don't understand the problem you're trying to solve. You seem to be
adding complexity for no good reason.
--
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/d37bf67a-0a14-4143-b09a-87fe96b6f90b%40isocpp.org.
------=_Part_1486_256279649.1533566845308
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 6, 2018 at 8:15:58 AM UTC-4, picpps...@g=
mail.com 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=
">Hello,<br><br>Referring to the p1073r1 I was thinking about whether there=
makes sense in reducing resuability of code in order to be sure to execute=
the code in compile-time.<br><br>This seems to not be an issue at all, whe=
n there is constexpr! and non-constexpr! function defined, because we can p=
rovide optimized version of the code for runtime and=C2=A0<br>compile-time =
version for compile-time context.=C2=A0<br><br>I guess there still might be=
a use case of executing constexpr! function when it's non-constexpr! t=
win is not defined at all.</div></blockquote><div><br></div><div>If the wri=
ter of that function did not provide a non-`constexpr` overload, then they =
<i>do not want</i> that function to be called outside of constant expressio=
n contexts. Maybe it's simply not meaningful to call it then. Maybe the=
re's no real point to it. Maybe the function exists solely to do type c=
omputation, and the function therefore only needs to be "executed"=
; for the purpose of `decltype` statements or other similar constant expres=
sion contexts.<br></div><div><br></div><div>Whatever the case, if a user ha=
s decided that this function should only be executed at compile time, then =
we should honor that decision.</div><div><br></div><div>I don't underst=
and the problem you're trying to solve. You seem to be adding complexit=
y for no good reason.<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/d37bf67a-0a14-4143-b09a-87fe96b6f90b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d37bf67a-0a14-4143-b09a-87fe96b6f90b=
%40isocpp.org</a>.<br />
------=_Part_1486_256279649.1533566845308--
------=_Part_1485_1337282239.1533566845308--
.
Author: Dawid Pilarski <picppstandard@gmail.com>
Date: Mon, 6 Aug 2018 19:47:56 +0200
Raw View
--000000000000a3c6ac0572c7e0f0
Content-Type: text/plain; charset="UTF-8"
>
> Maybe the function exists solely to do type computation
In fact I haven't thought of type computations (usually doing it with
structures, but you're right). Thanks for pointing this out.
I don't understand the problem you're trying to solve
Just to explain myself. I thought, that the primary issue, that p1073r1 was
trying to solve is to provide the mechanism to be able to know for sure,
that given function will be executed in compile time.
I thought, that instead of forbidding a function to be called at runtime at
the definition, maybe it's better to introduce some calling syntax, that
will help developer to force compile error if constexpr function is to be
ran in runtime.
As there is good use case for forbidding constexpr function to be called
in runtime I find post of mine to be not relevant anymore. Thank you
Nicolas for your time.
2018-08-06 16:47 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:
> On Monday, August 6, 2018 at 8:15:58 AM UTC-4, picpps...@gmail.com wrote:
>>
>> Hello,
>>
>> Referring to the p1073r1 I was thinking about whether there makes sense
>> in reducing resuability of code in order to be sure to execute the code in
>> compile-time.
>>
>> This seems to not be an issue at all, when there is constexpr! and
>> non-constexpr! function defined, because we can provide optimized version
>> of the code for runtime and
>> compile-time version for compile-time context.
>>
>> I guess there still might be a use case of executing constexpr! function
>> when it's non-constexpr! twin is not defined at all.
>>
>
> If the writer of that function did not provide a non-`constexpr` overload,
> then they *do not want* that function to be called outside of constant
> expression contexts. Maybe it's simply not meaningful to call it then.
> Maybe there's no real point to it. Maybe the function exists solely to do
> type computation, and the function therefore only needs to be "executed"
> for the purpose of `decltype` statements or other similar constant
> expression contexts.
>
> Whatever the case, if a user has decided that this function should only be
> executed at compile time, then we should honor that decision.
>
> I don't understand the problem you're trying to solve. You seem to be
> adding complexity for no good reason.
>
> --
> 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/d37bf67a-0a14-4143-
> b09a-87fe96b6f90b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d37bf67a-0a14-4143-b09a-87fe96b6f90b%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqgAg6xPs5H43jM8FMnJp6m-jL3j4u0snP1RrjxvzOQaA%40mail.gmail.com.
--000000000000a3c6ac0572c7e0f0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Maybe th=
e function exists solely to do type computation</blockquote><div><br></div>=
<div>In fact I haven't thought of type computations (usually doing it w=
ith structures, but you're right). Thanks for pointing this out.<br><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">
I don't understand the problem you're trying to solve
</blockquote><div><br></div><div>Just to explain myself. I thought, that th=
e primary issue, that p1073r1 was trying to solve is to provide the mechani=
sm to be able to know for sure, that given function will be executed in com=
pile time.<br></div><div>I thought, that instead of forbidding a function t=
o be called at runtime at the definition, maybe it's better to introduc=
e some calling syntax, that will help developer to force compile error if c=
onstexpr function is to be ran in runtime.<br><br></div><div>As there is go=
od use case for forbidding constexpr function to be called=C2=A0 in runtime=
I find post of mine to be not relevant anymore. Thank you Nicolas for your=
time.<br></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">2018-08-06 16:47 GMT+02:00 Nicol Bolas <span dir=3D"ltr"><<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span cla=
ss=3D"">On Monday, August 6, 2018 at 8:15:58 AM UTC-4, <a href=3D"mailto:pi=
cpps...@gmail.com" target=3D"_blank">picpps...@gmail.com</a> wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello,<br><br>Referring to=
the p1073r1 I was thinking about whether there makes sense in reducing res=
uability of code in order to be sure to execute the code in compile-time.<b=
r><br>This seems to not be an issue at all, when there is constexpr! and no=
n-constexpr! function defined, because we can provide optimized version of =
the code for runtime and=C2=A0<br>compile-time version for compile-time con=
text.=C2=A0<br><br>I guess there still might be a use case of executing con=
stexpr! function when it's non-constexpr! twin is not defined at all.</=
div></blockquote><div><br></div></span><div>If the writer of that function =
did not provide a non-`constexpr` overload, then they <i>do not want</i> th=
at function to be called outside of constant expression contexts. Maybe it&=
#39;s simply not meaningful to call it then. Maybe there's no real poin=
t to it. Maybe the function exists solely to do type computation, and the f=
unction therefore only needs to be "executed" for the purpose of =
`decltype` statements or other similar constant expression contexts.<br></d=
iv><div><br></div><div>Whatever the case, if a user has decided that this f=
unction should only be executed at compile time, then we should honor that =
decision.</div><div><br></div><div>I don't understand the problem you&#=
39;re trying to solve. You seem to be adding complexity for no good reason.=
<br></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d37bf67a-0a14-4143-b09a-87fe96b6f90b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/d37b=
f67a-0a14-4143-<wbr>b09a-87fe96b6f90b%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqgAg6xPs5H43jM8FMnJp6m-jL3j4u0=
snP1RrjxvzOQaA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqgAg6xPs5H=
43jM8FMnJp6m-jL3j4u0snP1RrjxvzOQaA%40mail.gmail.com</a>.<br />
--000000000000a3c6ac0572c7e0f0--
.
Author: Nicolas Lesser <blitzrakete@gmail.com>
Date: Mon, 6 Aug 2018 11:24:02 -0700
Raw View
--00000000000013273b0572c86337
Content-Type: text/plain; charset="UTF-8"
I don't like this idea.
constexpr!, or immediate functions, are proposed because they are useful
for reflections, where you might have to have a function that can only be
called at compile-time because it does some reflection stuff. constexpr is
not enough for it, as a constexpr function can also be called with runtime
arguments, and you can't reflect on runtime stuff. Now you're saying to
lift this requirement? That would mean that there would be no difference
between constexpr and immediate functions. Also, I don't really like
"constexpr overloading" because a constexpr function can also be called at
runtime, there is no inherit reason to think that a constexpr function
should only be called at runtime; I think a better idea for this is
std::is_constant_evaluated() (P0595).
I thought, that instead of forbidding a function to be called at runtime at
> the definition, maybe it's better to introduce some calling syntax, that
> will help developer to force compile error if constexpr function is to be
> ran in runtime.
>
No. As already said, immediate functions *cannot* be called at runtime if
they use for example reflection stuff. Putting that requirement on the
caller is a bit weird; that would mean that every call to an immediate call
would have to be prefixed by `constexpr`?
But I also don't see the motivation for allowing such a constexpr call
syntax for constexpr functions. What's the motivation for this?
On Mon, Aug 6, 2018 at 10:47 AM Dawid Pilarski <picppstandard@gmail.com>
wrote:
> Maybe the function exists solely to do type computation
>
>
> In fact I haven't thought of type computations (usually doing it with
> structures, but you're right). Thanks for pointing this out.
>
> I don't understand the problem you're trying to solve
>
>
> Just to explain myself. I thought, that the primary issue, that p1073r1
> was trying to solve is to provide the mechanism to be able to know for
> sure, that given function will be executed in compile time.
> I thought, that instead of forbidding a function to be called at runtime
> at the definition, maybe it's better to introduce some calling syntax, that
> will help developer to force compile error if constexpr function is to be
> ran in runtime.
>
> As there is good use case for forbidding constexpr function to be called
> in runtime I find post of mine to be not relevant anymore. Thank you
> Nicolas for your time.
>
> 2018-08-06 16:47 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:
>
>> On Monday, August 6, 2018 at 8:15:58 AM UTC-4, picpps...@gmail.com wrote:
>>>
>>> Hello,
>>>
>>> Referring to the p1073r1 I was thinking about whether there makes sense
>>> in reducing resuability of code in order to be sure to execute the code in
>>> compile-time.
>>>
>>> This seems to not be an issue at all, when there is constexpr! and
>>> non-constexpr! function defined, because we can provide optimized version
>>> of the code for runtime and
>>> compile-time version for compile-time context.
>>>
>>> I guess there still might be a use case of executing constexpr! function
>>> when it's non-constexpr! twin is not defined at all.
>>>
>>
>> If the writer of that function did not provide a non-`constexpr`
>> overload, then they *do not want* that function to be called outside of
>> constant expression contexts. Maybe it's simply not meaningful to call it
>> then. Maybe there's no real point to it. Maybe the function exists solely
>> to do type computation, and the function therefore only needs to be
>> "executed" for the purpose of `decltype` statements or other similar
>> constant expression contexts.
>>
>> Whatever the case, if a user has decided that this function should only
>> be executed at compile time, then we should honor that decision.
>>
>> I don't understand the problem you're trying to solve. You seem to be
>> adding complexity for no good reason.
>>
>> --
>> 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/d37bf67a-0a14-4143-b09a-87fe96b6f90b%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d37bf67a-0a14-4143-b09a-87fe96b6f90b%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqgAg6xPs5H43jM8FMnJp6m-jL3j4u0snP1RrjxvzOQaA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqgAg6xPs5H43jM8FMnJp6m-jL3j4u0snP1RrjxvzOQaA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq39Vm7EE%2Bbmz78FHKuBB2JhWSFaat_wq8PDcKaOyUVg2w%40mail.gmail.com.
--00000000000013273b0572c86337
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't like this idea.<div><br></div><div>constexpr!,=
or immediate functions, are proposed because they are useful for reflectio=
ns, where you might have to have a function that can only be called at comp=
ile-time because it does some reflection stuff. constexpr is not enough for=
it, as a constexpr function can also be called with runtime arguments, and=
you can't reflect on runtime stuff. Now you're saying to lift this=
requirement? That would mean that there would be no difference between con=
stexpr and immediate functions. Also, I don't really like "constex=
pr overloading" because a constexpr function can also be called at run=
time, there is no inherit reason to think that a constexpr function should =
only be called at runtime; I think a better idea for this is std::is_consta=
nt_evaluated() (P0595).</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">I thought, that instead of forbidding a function to be c=
alled at runtime at the definition, maybe it's better to introduce some=
calling syntax, that will help developer to force compile error if constex=
pr function is to be ran in runtime.<br></blockquote><div><br></div><div>No=
.. As already said, immediate functions <i>cannot</i>=C2=A0be called at runt=
ime if they use for example reflection stuff. Putting that requirement on t=
he caller is a bit weird; that would mean that every call to an immediate c=
all would have to be prefixed by `constexpr`?=C2=A0</div><div><br></div><di=
v>But I also don't see the motivation for allowing such a constexpr cal=
l syntax for constexpr functions. What's the motivation for this?=C2=A0=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 6, =
2018 at 10:47 AM Dawid Pilarski <<a href=3D"mailto:picppstandard@gmail.c=
om">picppstandard@gmail.com</a>> wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
Maybe the function exists solely to do type computation</blockquote><div><b=
r></div><div>In fact I haven't thought of type computations (usually do=
ing it with structures, but you're right). Thanks for pointing this out=
..<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don't understand the problem you're trying to solve
</blockquote><div><br></div><div>Just to explain myself. I thought, that th=
e primary issue, that p1073r1 was trying to solve is to provide the mechani=
sm to be able to know for sure, that given function will be executed in com=
pile time.<br></div><div>I thought, that instead of forbidding a function t=
o be called at runtime at the definition, maybe it's better to introduc=
e some calling syntax, that will help developer to force compile error if c=
onstexpr function is to be ran in runtime.<br><br></div><div>As there is go=
od use case for forbidding constexpr function to be called=C2=A0 in runtime=
I find post of mine to be not relevant anymore. Thank you Nicolas for your=
time.<br></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">2018-08-06 16:47 GMT+02:00 Nicol Bolas <span dir=3D"ltr"><<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On =
Monday, August 6, 2018 at 8:15:58 AM UTC-4, <a href=3D"mailto:picpps...@gma=
il.com" target=3D"_blank">picpps...@gmail.com</a> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Hello,<br><br>Referring to the p107=
3r1 I was thinking about whether there makes sense in reducing resuability =
of code in order to be sure to execute the code in compile-time.<br><br>Thi=
s seems to not be an issue at all, when there is constexpr! and non-constex=
pr! function defined, because we can provide optimized version of the code =
for runtime and=C2=A0<br>compile-time version for compile-time context.=C2=
=A0<br><br>I guess there still might be a use case of executing constexpr! =
function when it's non-constexpr! twin is not defined at all.</div></bl=
ockquote><div><br></div></span><div>If the writer of that function did not =
provide a non-`constexpr` overload, then they <i>do not want</i> that funct=
ion to be called outside of constant expression contexts. Maybe it's si=
mply not meaningful to call it then. Maybe there's no real point to it.=
Maybe the function exists solely to do type computation, and the function =
therefore only needs to be "executed" for the purpose of `decltyp=
e` statements or other similar constant expression contexts.<br></div><div>=
<br></div><div>Whatever the case, if a user has decided that this function =
should only be executed at compile time, then we should honor that decision=
..</div><div><br></div><div>I don't understand the problem you're tr=
ying to solve. You seem to be adding complexity for no good reason.<br></di=
v></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d37bf67a-0a14-4143-b09a-87fe96b6f90b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d37bf67a-0a14-=
4143-b09a-87fe96b6f90b%40isocpp.org</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqgAg6xPs5H43jM8FMnJp6m-jL3j4u0=
snP1RrjxvzOQaA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAJsLGmqgAg6xPs5H43jM8FMnJp6m-jL3j4u0snP1RrjxvzOQaA%40mail.gmail.com</=
a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq39Vm7EE%2Bbmz78FHKuBB2JhWSFaat=
_wq8PDcKaOyUVg2w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq39Vm7EE%=
2Bbmz78FHKuBB2JhWSFaat_wq8PDcKaOyUVg2w%40mail.gmail.com</a>.<br />
--00000000000013273b0572c86337--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 6 Aug 2018 13:23:35 -0700 (PDT)
Raw View
------=_Part_1499_652421276.1533587015171
Content-Type: multipart/alternative;
boundary="----=_Part_1500_239259945.1533587015171"
------=_Part_1500_239259945.1533587015171
Content-Type: text/plain; charset="UTF-8"
On Monday, August 6, 2018 at 2:24:27 PM UTC-4, Nicolas Lesser wrote:
>
> I don't like this idea.
>
> constexpr!, or immediate functions, are proposed because they are useful
> for reflections, where you might have to have a function that can only be
> called at compile-time because it does some reflection stuff. constexpr is
> not enough for it, as a constexpr function can also be called with runtime
> arguments, and you can't reflect on runtime stuff. Now you're saying to
> lift this requirement? That would mean that there would be no difference
> between constexpr and immediate functions. Also, I don't really like
> "constexpr overloading" because a constexpr function can also be called at
> runtime, there is no inherit reason to think that a constexpr function
> should only be called at runtime; I think a better idea for this is
> std::is_constant_evaluated() (P0595).
>
I see no reason why we shouldn't have both `constexpr!` with overloading
and `is_constant_evaluated`.
If the implementations of the two functions are going to be fundamentally
different, I'd rather write them as two separate functions and let
overloading do its job than to have to write a `constexpr` function that
wraps the two implementations in an `if constexpr`. It's more
self-documenting that way.
By contrast, there can be times when the non-constexpr version is the same
as the constexpr one, except that maybe it does some file logging. So doing
an `if constexpr(!is_constant_evaluated())` to surround such blocks is
perfectly valid.
So long as the overloading rules are pretty obvious, there isn't really a
problem with `constexpr!` overloading.
--
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/9bb74391-51b6-4b45-877a-6374bb1015d9%40isocpp.org.
------=_Part_1500_239259945.1533587015171
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 6, 2018 at 2:24:27 PM UTC-4, Nicolas Les=
ser 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">I d=
on't like this idea.<div><br></div><div>constexpr!, or immediate functi=
ons, are proposed because they are useful for reflections, where you might =
have to have a function that can only be called at compile-time because it =
does some reflection stuff. constexpr is not enough for it, as a constexpr =
function can also be called with runtime arguments, and you can't refle=
ct on runtime stuff. Now you're saying to lift this requirement? That w=
ould mean that there would be no difference between constexpr and immediate=
functions. Also, I don't really like "constexpr overloading"=
because a constexpr function can also be called at runtime, there is no in=
herit reason to think that a constexpr function should only be called at ru=
ntime; I think a better idea for this is std::is_constant_evaluated() (P059=
5).</div></div></blockquote><div><br></div><div>I see no reason why we shou=
ldn't have both `constexpr!` with overloading and `is_constant_evaluate=
d`.</div><div><br></div><div>If the implementations of the two functions ar=
e going to be fundamentally different, I'd rather write them as two sep=
arate functions and let overloading do its job than to have to write a `con=
stexpr` function that wraps the two implementations in an `if constexpr`. I=
t's more self-documenting that way.</div><div><br></div><div>By contras=
t, there can be times when the non-constexpr version is the same as the con=
stexpr one, except that maybe it does some file logging. So doing an `if co=
nstexpr(!is_constant_evaluated())` to surround such blocks is perfectly val=
id.</div><div><br></div><div>So long as the overloading rules are pretty ob=
vious, there isn't really a problem with `constexpr!` overloading.<br><=
/div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9bb74391-51b6-4b45-877a-6374bb1015d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9bb74391-51b6-4b45-877a-6374bb1015d9=
%40isocpp.org</a>.<br />
------=_Part_1500_239259945.1533587015171--
------=_Part_1499_652421276.1533587015171--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 6 Aug 2018 23:49:22 +0300
Raw View
On 6 August 2018 at 23:23, Nicol Bolas <jmckesson@gmail.com> wrote:
> By contrast, there can be times when the non-constexpr version is the same
> as the constexpr one, except that maybe it does some file logging. So doing
> an `if constexpr(!is_constant_evaluated())` to surround such blocks is
> perfectly valid.
That condition is always false, so I don't know what you're getting at.
--
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/CAFk2RUZc8QQiRtPP_NujrQCSuS8ahTvqz2Y19CYB0%2BbyqOdzcg%40mail.gmail.com.
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Mon, 6 Aug 2018 15:26:49 -0700 (PDT)
Raw View
------=_Part_1529_1221205856.1533594410046
Content-Type: multipart/alternative;
boundary="----=_Part_1530_1635595852.1533594410046"
------=_Part_1530_1635595852.1533594410046
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Voutilainen wrote:
>
> On 6 August 2018 at 23:23, Nicol Bolas <jmck...@gmail.com <javascript:>>=
=20
> wrote:=20
> > By contrast, there can be times when the non-constexpr version is the=
=20
> same=20
> > as the constexpr one, except that maybe it does some file logging. So=
=20
> doing=20
> > an `if constexpr(!is_constant_evaluated())` to surround such blocks is=
=20
> > perfectly valid.=20
>
> That condition is always false, so I don't know what you're getting at.=
=20
>
Yes you do.
There's an unfortunate tendency of several people in "constexpr"=20
discussions to treat the accidental behavior of
if constexpr(is_constant_evaluated()) {
do one thing
} else {
do another (but this code is in fact never executed, ha ha!)
}
as a gotcha to be used as a source of triumph over the unenlightened=20
masses, rather than a sad pothole in need of fixing up.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e428057b-a104-4ae2-a13f-734bb8449f49%40isocpp.or=
g.
------=_Part_1530_1635595852.1533594410046
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Vouti=
lainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 6 August 2018 =
at 23:23, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"GE9grUttDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">jmck...@gmail.com</a>> wrote:
<br>> By contrast, there can be times when the non-constexpr version is =
the same
<br>> as the constexpr one, except that maybe it does some file logging.=
So doing
<br>> an `if constexpr(!is_constant_<wbr>evaluated())` to surround such =
blocks is
<br>> perfectly valid.
<br>
<br>That condition is always false, so I don't know what you're get=
ting at.
<br></blockquote><div><br></div><div>Yes you do.</div><div><br></div><div><=
br></div><div>There's an unfortunate tendency of several people in &quo=
t;constexpr" discussions to treat the accidental behavior of</div><div=
><br></div><div>=C2=A0 =C2=A0 if constexpr(is_constant_evaluated()) {</div>=
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 do one thing</div><div>=C2=A0 =C2=A0 } els=
e {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 do another (but this code is in f=
act never executed, ha ha!)</div><div>=C2=A0 =C2=A0 }</div><div><br></div><=
div>as a gotcha to be used as a source of triumph over the unenlightened ma=
sses, rather than a sad pothole in need of fixing up.</div><div><br></div><=
div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e428057b-a104-4ae2-a13f-734bb8449f49%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e428057b-a104-4ae2-a13f-734bb8449f49=
%40isocpp.org</a>.<br />
------=_Part_1530_1635595852.1533594410046--
------=_Part_1529_1221205856.1533594410046--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 7 Aug 2018 01:41:49 +0300
Raw View
On 7 August 2018 at 01:26, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
> On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Voutilainen wrote:
>>
>> On 6 August 2018 at 23:23, Nicol Bolas <jmck...@gmail.com> wrote:
>> > By contrast, there can be times when the non-constexpr version is the
>> > same
>> > as the constexpr one, except that maybe it does some file logging. So
>> > doing
>> > an `if constexpr(!is_constant_evaluated())` to surround such blocks is
>> > perfectly valid.
>>
>> That condition is always false, so I don't know what you're getting at.
>
>
> Yes you do.
>
>
> There's an unfortunate tendency of several people in "constexpr" discussions
> to treat the accidental behavior of
That behavior is not accidental.
--
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/CAFk2RUbh5dT%3DHHJ-NOS5ZM2dybePpaWEYQnu1Tm5x%3DbXh5f3ZA%40mail.gmail.com.
.
Author: bastienpenava@gmail.com
Date: Mon, 6 Aug 2018 15:55:25 -0700 (PDT)
Raw View
------=_Part_1516_94082250.1533596125914
Content-Type: multipart/alternative;
boundary="----=_Part_1517_1793418160.1533596125914"
------=_Part_1517_1793418160.1533596125914
Content-Type: text/plain; charset="UTF-8"
On Tuesday, August 7, 2018 at 12:41:51 AM UTC+2, Ville Voutilainen wrote:
>
> On 7 August 2018 at 01:26, Arthur O'Dwyer <arthur....@gmail.com
> <javascript:>> wrote:
> > On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Voutilainen wrote:
> >>
> >> On 6 August 2018 at 23:23, Nicol Bolas <jmck...@gmail.com> wrote:
> >> > By contrast, there can be times when the non-constexpr version is the
> >> > same
> >> > as the constexpr one, except that maybe it does some file logging. So
> >> > doing
> >> > an `if constexpr(!is_constant_evaluated())` to surround such blocks
> is
> >> > perfectly valid.
> >>
> >> That condition is always false, so I don't know what you're getting at.
> >
> >
> > Yes you do.
> >
> >
> > There's an unfortunate tendency of several people in "constexpr"
> discussions
> > to treat the accidental behavior of
>
> That behavior is not accidental.
>
Yes it's worse, it's confusing by design.
I don't see that being a factor to the "simple language trying to
breakthrough".
I've already seen that "not accidental" behavior being misinterpreted and
by people who have a pretty good understanding and long time experience of
C++.
I don't see that stopping anytime soon.
std::is_constant_evaluated() is confusing because the only thing it does is
that it has compile time side effects on simple if, turning them into
bastardized version of "if constexpr" but without the interesting part of
"if constexpr".
It is logical and normal that the user would then try to combine it with an
"if constexpr" when what they want is to specialize.
When the "static if" conversation arise wasn't the argument that we didn't
need it because we could use concepts to specialize?
And now that "static if" was trampled over to become "if constexpr" we want
a weird intermediate between "if" and "if constexpr" through a built-in
function to avoid allowing the user to specialize constexpr-ness?
Good to know.
--
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/76eaf276-ade3-413c-9359-92372e3ba19e%40isocpp.org.
------=_Part_1517_1793418160.1533596125914
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, August 7, 2018 at 12:41:51 AM UTC+2, V=
ille Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 7 Au=
gust 2018 at 01:26, Arthur O'Dwyer <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"z8WhRW5zDgAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">arthur....@gmail.com</a>> wrote:
<br>> On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Voutilainen w=
rote:
<br>>>
<br>>> On 6 August 2018 at 23:23, Nicol Bolas <<a>jmck...@gmail.co=
m</a>> wrote:
<br>>> > By contrast, there can be times when the non-constexpr ve=
rsion is the
<br>>> > same
<br>>> > as the constexpr one, except that maybe it does some file=
logging. So
<br>>> > doing
<br>>> > an `if constexpr(!is_constant_<wbr>evaluated())` to surro=
und such blocks is
<br>>> > perfectly valid.
<br>>>
<br>>> That condition is always false, so I don't know what you&#=
39;re getting at.
<br>>
<br>>
<br>> Yes you do.
<br>>
<br>>
<br>> There's an unfortunate tendency of several people in "con=
stexpr" discussions
<br>> to treat the accidental behavior of
<br>
<br>That behavior is not accidental.
<br></blockquote><div>=C2=A0</div><div>Yes it's worse, it's confusi=
ng by design.</div><div>I don't see that being a factor to the "si=
mple language trying to breakthrough".</div><div>I've already seen=
that "not accidental" behavior being misinterpreted and by peopl=
e who have a pretty good understanding and long time experience of C++.</di=
v><div>I don't see that stopping anytime soon.<br></div><div>std::is_co=
nstant_evaluated() is confusing because the only thing it does is that it h=
as compile time side effects on simple if, turning them into bastardized ve=
rsion of "if constexpr" but without the interesting part of "=
;if constexpr".<br></div><div>It is logical and normal that the user w=
ould then try to combine it with an "if constexpr" when what they=
want is to specialize.</div><div><div>When the "static if" conve=
rsation arise wasn't the argument that we didn't need it because we=
could use concepts to specialize?</div><div>And now that "static if&q=
uot; was trampled over to become "if constexpr" we want a weird i=
ntermediate between "if" and "if constexpr" through a b=
uilt-in function to avoid allowing the user to specialize constexpr-ness?</=
div></div><div>Good to know.</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/76eaf276-ade3-413c-9359-92372e3ba19e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/76eaf276-ade3-413c-9359-92372e3ba19e=
%40isocpp.org</a>.<br />
------=_Part_1517_1793418160.1533596125914--
------=_Part_1516_94082250.1533596125914--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 6 Aug 2018 17:51:40 -0700 (PDT)
Raw View
------=_Part_460_291716168.1533603100925
Content-Type: multipart/alternative;
boundary="----=_Part_461_1273561036.1533603100925"
------=_Part_461_1273561036.1533603100925
Content-Type: text/plain; charset="UTF-8"
On Monday, August 6, 2018 at 6:55:26 PM UTC-4, bastie...@gmail.com wrote:
>
>
>
> On Tuesday, August 7, 2018 at 12:41:51 AM UTC+2, Ville Voutilainen wrote:
>>
>> On 7 August 2018 at 01:26, Arthur O'Dwyer <arthur....@gmail.com> wrote:
>> > On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Voutilainen wrote:
>> >>
>> >> On 6 August 2018 at 23:23, Nicol Bolas <jmck...@gmail.com> wrote:
>> >> > By contrast, there can be times when the non-constexpr version is
>> the
>> >> > same
>> >> > as the constexpr one, except that maybe it does some file logging.
>> So
>> >> > doing
>> >> > an `if constexpr(!is_constant_evaluated())` to surround such blocks
>> is
>> >> > perfectly valid.
>> >>
>> >> That condition is always false, so I don't know what you're getting
>> at.
>> >
>> >
>> > Yes you do.
>> >
>> >
>> > There's an unfortunate tendency of several people in "constexpr"
>> discussions
>> > to treat the accidental behavior of
>>
>> That behavior is not accidental.
>>
>
> Yes it's worse, it's confusing by design.
>
It's rather like the Most Vexing Parse. MVP is based on an unfortunate
combination of the ambiguity between a possible function declaration and a
variable declaration initialized via constructor-call syntax. We can all
understand why it's there, but we all would rather it not be there.
Only this time, the ambiguity is discovered before the feature became
standard. So... why are we still doing it that way?
In fact, looking over P0595, it's actually negatively useful as a feature.
It is only allowed to evaluate to "true" in cases where the expression is
*required* to be a constant expression; it *must* evaluate to "false" in
other cases, even if the compiler wants to run it at compile time. So you
cannot use it for cases where there is a divergence between efficient the
compile-time and runtime solutions.
So what good is the feature at all?
--
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/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534%40isocpp.org.
------=_Part_461_1273561036.1533603100925
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, August 6, 2018 at 6:55:26 PM UTC-4, bas=
tie...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><br><br>On Tuesday, August 7, 2018 at 12:41:51 AM UTC+2, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 7 August 2018 at=
01:26, Arthur O'Dwyer <<a rel=3D"nofollow">arthur....@gmail.com</a>=
> wrote:
<br>> On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Voutilainen w=
rote:
<br>>>
<br>>> On 6 August 2018 at 23:23, Nicol Bolas <<a>jmck...@gmail.co=
m</a>> wrote:
<br>>> > By contrast, there can be times when the non-constexpr ve=
rsion is the
<br>>> > same
<br>>> > as the constexpr one, except that maybe it does some file=
logging. So
<br>>> > doing
<br>>> > an `if constexpr(!is_constant_<wbr>evaluated())` to surro=
und such blocks is
<br>>> > perfectly valid.
<br>>>
<br>>> That condition is always false, so I don't know what you&#=
39;re getting at.
<br>>
<br>>
<br>> Yes you do.
<br>>
<br>>
<br>> There's an unfortunate tendency of several people in "con=
stexpr" discussions
<br>> to treat the accidental behavior of
<br>
<br>That behavior is not accidental.
<br></blockquote><div>=C2=A0</div><div>Yes it's worse, it's confusi=
ng by design.</div></div></blockquote><div><br></div><div>It's rather l=
ike the Most Vexing Parse. MVP is based on an unfortunate combination of th=
e ambiguity between a possible function declaration and a variable declarat=
ion initialized via constructor-call syntax. We can all understand why it&#=
39;s there, but we all would rather it not be there.</div><div><br></div><d=
iv>Only this time, the ambiguity is discovered before the feature became st=
andard. So... why are we still doing it that way?</div><div><br></div><div>=
In fact, looking over P0595, it's actually negatively useful as a featu=
re. It is only allowed to evaluate to "true" in cases where the e=
xpression is <i>required</i> to be a constant expression; it <i>must</i> ev=
aluate to "false" in other cases, even if the compiler wants to r=
un it at compile time. So you cannot use it for cases where there is a dive=
rgence between efficient the compile-time and runtime solutions.</div><div>=
<br></div><div>So what good is the feature at all?<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/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534=
%40isocpp.org</a>.<br />
------=_Part_461_1273561036.1533603100925--
------=_Part_460_291716168.1533603100925--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 7 Aug 2018 08:41:15 +0300
Raw View
On 7 August 2018 at 03:51, Nicol Bolas <jmckesson@gmail.com> wrote:
> In fact, looking over P0595, it's actually negatively useful as a feature.
> It is only allowed to evaluate to "true" in cases where the expression is
> required to be a constant expression; it must evaluate to "false" in other
> cases, even if the compiler wants to run it at compile time. So you cannot
> use it for cases where there is a divergence between efficient the
> compile-time and runtime solutions.
>
> So what good is the feature at all?
It gives you a portable result, as opposed to a result that depends on
whether your implementation
folds or not. Just use a normal if instead of if constexpr and it'll
do what you want.
--
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/CAFk2RUbr9LDQdZnKmUHuXw5vAZ%2BBmGVCBj4woomMafKty_wkiQ%40mail.gmail.com.
.
Author: Dawid Pilarski <picppstandard@gmail.com>
Date: Tue, 7 Aug 2018 07:53:12 +0200
Raw View
--0000000000007156ee0572d202a0
Content-Type: text/plain; charset="UTF-8"
@Nicolas Lesser
What's the motivation for this?
>
I will try to share with you my motivation.
there can be some numerical computation done in the constexpr function. For
me it's important, that in some usages it will be compile time evaluated,
otherwise I cannot fulfill my agreement with the user regarding performance.
So now I want to call it
//context
my_contexpr_function_here(/*args*/);
//context
issues:
1. There is no way of checking whether the function really got executed in
compile time,
2. There is no way if informing the reader (instead of the comment) to let
him know that he must not break the compile-time evaluation of constexpr
function.
So in my case after writing things down, to be sure, that function is
compile-time evaluated I needed to check the generated code.
So, when I do:
constexpr my_contexpr_function_here(/*args*/);
when I do change in the code, I am sure, that if I break compile-time
evaluation I will get compile time error.
2018-08-07 2:51 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:
>
>
> On Monday, August 6, 2018 at 6:55:26 PM UTC-4, bastie...@gmail.com wrote:
>>
>>
>>
>> On Tuesday, August 7, 2018 at 12:41:51 AM UTC+2, Ville Voutilainen wrote:
>>>
>>> On 7 August 2018 at 01:26, Arthur O'Dwyer <arthur....@gmail.com> wrote:
>>> > On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Voutilainen
>>> wrote:
>>> >>
>>> >> On 6 August 2018 at 23:23, Nicol Bolas <jmck...@gmail.com> wrote:
>>> >> > By contrast, there can be times when the non-constexpr version is
>>> the
>>> >> > same
>>> >> > as the constexpr one, except that maybe it does some file logging.
>>> So
>>> >> > doing
>>> >> > an `if constexpr(!is_constant_evaluated())` to surround such
>>> blocks is
>>> >> > perfectly valid.
>>> >>
>>> >> That condition is always false, so I don't know what you're getting
>>> at.
>>> >
>>> >
>>> > Yes you do.
>>> >
>>> >
>>> > There's an unfortunate tendency of several people in "constexpr"
>>> discussions
>>> > to treat the accidental behavior of
>>>
>>> That behavior is not accidental.
>>>
>>
>> Yes it's worse, it's confusing by design.
>>
>
> It's rather like the Most Vexing Parse. MVP is based on an unfortunate
> combination of the ambiguity between a possible function declaration and a
> variable declaration initialized via constructor-call syntax. We can all
> understand why it's there, but we all would rather it not be there.
>
> Only this time, the ambiguity is discovered before the feature became
> standard. So... why are we still doing it that way?
>
> In fact, looking over P0595, it's actually negatively useful as a feature.
> It is only allowed to evaluate to "true" in cases where the expression is
> *required* to be a constant expression; it *must* evaluate to "false" in
> other cases, even if the compiler wants to run it at compile time. So you
> cannot use it for cases where there is a divergence between efficient the
> compile-time and runtime solutions.
>
> So what good is the feature at all?
>
> --
> 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/4c8c5f38-7e00-4b6a-
> a46a-c942e3e0a534%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqiFSA4xZieB8Y-1%2BLzXbZKvBtMprr3W%3Deasf14rMB%2B0g%40mail.gmail.com.
--0000000000007156ee0572d202a0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">@Nicolas Lesser<br><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><span style=3D"font-size:12.8px;background-color:rgb(255,255=
,255);text-decoration-style:initial;text-decoration-color:initial;float:non=
e;display:inline"><span>=C2=A0</span>What's the motivation for this?=C2=
=A0</span><br></blockquote><br>I will try to share with you my motivation.<=
div><br></div><div>there can be some numerical computation done in the cons=
texpr function. For me it's important, that in some usages it will be c=
ompile time evaluated, otherwise I cannot fulfill my agreement with the use=
r regarding performance.<br><br>So now I want to call it=C2=A0<br><br>//con=
text<br>my_contexpr_function_here(/*args*/);<br>//context</div><div><br>iss=
ues:<br>1. There is no way of checking whether the function really got exec=
uted in compile time,<br>2. There is no way if informing the reader (instea=
d of the comment) to let him know that he must not break the compile-time e=
valuation of constexpr function.<br><br>So in my case after writing things =
down, to be sure, that function is compile-time evaluated I needed to check=
the generated code.<br><br>So, when I do:<br><br>constexpr <span style=3D"=
font-size:small;background-color:rgb(255,255,255);text-decoration-style:ini=
tial;text-decoration-color:initial;float:none;display:inline">my_contexpr_f=
unction_here(/*args*/);<br></span><br>when I do change in the code, I am su=
re, that if I break compile-time evaluation I will get compile time error.<=
br><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">2018-08-07 2:51 GMT+02:00 Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><b=
r><br>On Monday, August 6, 2018 at 6:55:26 PM UTC-4, <a href=3D"mailto:bast=
ie...@gmail.com" target=3D"_blank">bastie...@gmail.com</a> wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Tuesday, August 7=
, 2018 at 12:41:51 AM UTC+2, Ville Voutilainen wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">On 7 August 2018 at 01:26, Arthur O'Dwyer <<a rel=
=3D"nofollow">arthur....@gmail.com</a>> wrote:
<br>> On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Voutilainen w=
rote:
<br>>>
<br>>> On 6 August 2018 at 23:23, Nicol Bolas <<a>jmck...@gmail.co=
m</a>> wrote:
<br>>> > By contrast, there can be times when the non-constexpr ve=
rsion is the
<br>>> > same
<br>>> > as the constexpr one, except that maybe it does some file=
logging. So
<br>>> > doing
<br>>> > an `if constexpr(!is_constant_evaluat<wbr>ed())` to surro=
und such blocks is
<br>>> > perfectly valid.
<br>>>
<br>>> That condition is always false, so I don't know what you&#=
39;re getting at.
<br>>
<br>>
<br>> Yes you do.
<br>>
<br>>
<br>> There's an unfortunate tendency of several people in "con=
stexpr" discussions
<br>> to treat the accidental behavior of
<br>
<br>That behavior is not accidental.
<br></blockquote><div>=C2=A0</div><div>Yes it's worse, it's confusi=
ng by design.</div></div></blockquote><div><br></div></span><div>It's r=
ather like the Most Vexing Parse. MVP is based on an unfortunate combinatio=
n of the ambiguity between a possible function declaration and a variable d=
eclaration initialized via constructor-call syntax. We can all understand w=
hy it's there, but we all would rather it not be there.</div><div><br><=
/div><div>Only this time, the ambiguity is discovered before the feature be=
came standard. So... why are we still doing it that way?</div><div><br></di=
v><div>In fact, looking over P0595, it's actually negatively useful as =
a feature. It is only allowed to evaluate to "true" in cases wher=
e the expression is <i>required</i> to be a constant expression; it <i>must=
</i> evaluate to "false" in other cases, even if the compiler wan=
ts to run it at compile time. So you cannot use it for cases where there is=
a divergence between efficient the compile-time and runtime solutions.</di=
v><div><br></div><div>So what good is the feature at all?<br></div></div><s=
pan class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4c8c=
5f38-7e00-4b6a-<wbr>a46a-c942e3e0a534%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqiFSA4xZieB8Y-1%2BLzXbZKvBtMpr=
r3W%3Deasf14rMB%2B0g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqiFS=
A4xZieB8Y-1%2BLzXbZKvBtMprr3W%3Deasf14rMB%2B0g%40mail.gmail.com</a>.<br />
--0000000000007156ee0572d202a0--
.
Author: Nicolas Lesser <blitzrakete@gmail.com>
Date: Mon, 6 Aug 2018 23:27:48 -0700
Raw View
--000000000000ca67ce0572d27e4b
Content-Type: text/plain; charset="UTF-8"
Oh ok. Well, in that case, I would do:
constexpr auto result = foo(/*args*/);
so that foo is evaluated at compile-time. There's some talk about adding a
constexpr compound statement, where everything in it would be constant
evaluated so that would also solve your problem in a way (you might want to
look into that).
On Mon, Aug 6, 2018, 10:53 PM Dawid Pilarski <picppstandard@gmail.com>
wrote:
> @Nicolas Lesser
>
> What's the motivation for this?
>>
>
> I will try to share with you my motivation.
>
> there can be some numerical computation done in the constexpr function.
> For me it's important, that in some usages it will be compile time
> evaluated, otherwise I cannot fulfill my agreement with the user regarding
> performance.
>
> So now I want to call it
>
> //context
> my_contexpr_function_here(/*args*/);
> //context
>
> issues:
> 1. There is no way of checking whether the function really got executed in
> compile time,
> 2. There is no way if informing the reader (instead of the comment) to let
> him know that he must not break the compile-time evaluation of constexpr
> function.
>
> So in my case after writing things down, to be sure, that function is
> compile-time evaluated I needed to check the generated code.
>
> So, when I do:
>
> constexpr my_contexpr_function_here(/*args*/);
>
> when I do change in the code, I am sure, that if I break compile-time
> evaluation I will get compile time error.
>
>
> 2018-08-07 2:51 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:
>
>>
>>
>> On Monday, August 6, 2018 at 6:55:26 PM UTC-4, bastie...@gmail.com wrote:
>>>
>>>
>>>
>>> On Tuesday, August 7, 2018 at 12:41:51 AM UTC+2, Ville Voutilainen wrote:
>>>>
>>>> On 7 August 2018 at 01:26, Arthur O'Dwyer <arthur....@gmail.com>
>>>> wrote:
>>>> > On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Voutilainen
>>>> wrote:
>>>> >>
>>>> >> On 6 August 2018 at 23:23, Nicol Bolas <jmck...@gmail.com> wrote:
>>>> >> > By contrast, there can be times when the non-constexpr version is
>>>> the
>>>> >> > same
>>>> >> > as the constexpr one, except that maybe it does some file logging.
>>>> So
>>>> >> > doing
>>>> >> > an `if constexpr(!is_constant_evaluated())` to surround such
>>>> blocks is
>>>> >> > perfectly valid.
>>>> >>
>>>> >> That condition is always false, so I don't know what you're getting
>>>> at.
>>>> >
>>>> >
>>>> > Yes you do.
>>>> >
>>>> >
>>>> > There's an unfortunate tendency of several people in "constexpr"
>>>> discussions
>>>> > to treat the accidental behavior of
>>>>
>>>> That behavior is not accidental.
>>>>
>>>
>>> Yes it's worse, it's confusing by design.
>>>
>>
>> It's rather like the Most Vexing Parse. MVP is based on an unfortunate
>> combination of the ambiguity between a possible function declaration and a
>> variable declaration initialized via constructor-call syntax. We can all
>> understand why it's there, but we all would rather it not be there.
>>
>> Only this time, the ambiguity is discovered before the feature became
>> standard. So... why are we still doing it that way?
>>
>> In fact, looking over P0595, it's actually negatively useful as a
>> feature. It is only allowed to evaluate to "true" in cases where the
>> expression is *required* to be a constant expression; it *must* evaluate
>> to "false" in other cases, even if the compiler wants to run it at compile
>> time. So you cannot use it for cases where there is a divergence between
>> efficient the compile-time and runtime solutions.
>>
>> So what good is the feature at all?
>>
>> --
>> 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/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqiFSA4xZieB8Y-1%2BLzXbZKvBtMprr3W%3Deasf14rMB%2B0g%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqiFSA4xZieB8Y-1%2BLzXbZKvBtMprr3W%3Deasf14rMB%2B0g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2KqeoV-_KgtNo%3Dcg8bRxELsY3b4f8WxS9fDHjJMwe%3DVQ%40mail.gmail.com.
--000000000000ca67ce0572d27e4b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>Oh ok. Well, in that case, I would do:</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">constexpr auto result =3D foo(/*args*=
/);</div><div dir=3D"auto"><br></div><div dir=3D"auto">so that foo is evalu=
ated at compile-time. There's some talk about adding a constexpr compou=
nd statement, where everything in it would be constant evaluated so that wo=
uld also solve your problem in a way (you might want to look into that).=C2=
=A0<br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">On Mon,=
Aug 6, 2018, 10:53 PM Dawid Pilarski <<a href=3D"mailto:picppstandard@g=
mail.com">picppstandard@gmail.com</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">@Nicolas Lesser<br><br><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><span style=3D"font-size:12.8px;background-col=
or:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:ini=
tial;float:none;display:inline"><span>=C2=A0</span>What's the motivatio=
n for this?=C2=A0</span><br></blockquote><br>I will try to share with you m=
y motivation.<div><br></div><div>there can be some numerical computation do=
ne in the constexpr function. For me it's important, that in some usage=
s it will be compile time evaluated, otherwise I cannot fulfill my agreemen=
t with the user regarding performance.<br><br>So now I want to call it=C2=
=A0<br><br>//context<br>my_contexpr_function_here(/*args*/);<br>//context</=
div><div><br>issues:<br>1. There is no way of checking whether the function=
really got executed in compile time,<br>2. There is no way if informing th=
e reader (instead of the comment) to let him know that he must not break th=
e compile-time evaluation of constexpr function.<br><br>So in my case after=
writing things down, to be sure, that function is compile-time evaluated I=
needed to check the generated code.<br><br>So, when I do:<br><br>constexpr=
<span style=3D"font-size:small;background-color:rgb(255,255,255);text-deco=
ration-style:initial;text-decoration-color:initial;float:none;display:inlin=
e">my_contexpr_function_here(/*args*/);<br></span><br>when I do change in t=
he code, I am sure, that if I break compile-time evaluation I will get comp=
ile time error.<br><br></div></div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">2018-08-07 2:51 GMT+02:00 Nicol Bolas <span dir=3D"ltr">&=
lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank" rel=3D"noreferr=
er">jmckesson@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><span><br><br>On Monday, August 6, 2018 at 6:55:26 PM UTC-4=
, <a href=3D"mailto:bastie...@gmail.com" target=3D"_blank" rel=3D"noreferre=
r">bastie...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><br><br>On Tuesday, August 7, 2018 at 12:41:51 AM UTC+2, Vil=
le 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 7 August 20=
18 at 01:26, Arthur O'Dwyer <<a rel=3D"nofollow noreferrer">arthur..=
...@gmail.com</a>> wrote:
<br>> On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Voutilainen w=
rote:
<br>>>
<br>>> On 6 August 2018 at 23:23, Nicol Bolas <<a rel=3D"noreferre=
r">jmck...@gmail.com</a>> wrote:
<br>>> > By contrast, there can be times when the non-constexpr ve=
rsion is the
<br>>> > same
<br>>> > as the constexpr one, except that maybe it does some file=
logging. So
<br>>> > doing
<br>>> > an `if constexpr(!is_constant_evaluated())` to surround s=
uch blocks is
<br>>> > perfectly valid.
<br>>>
<br>>> That condition is always false, so I don't know what you&#=
39;re getting at.
<br>>
<br>>
<br>> Yes you do.
<br>>
<br>>
<br>> There's an unfortunate tendency of several people in "con=
stexpr" discussions
<br>> to treat the accidental behavior of
<br>
<br>That behavior is not accidental.
<br></blockquote><div>=C2=A0</div><div>Yes it's worse, it's confusi=
ng by design.</div></div></blockquote><div><br></div></span><div>It's r=
ather like the Most Vexing Parse. MVP is based on an unfortunate combinatio=
n of the ambiguity between a possible function declaration and a variable d=
eclaration initialized via constructor-call syntax. We can all understand w=
hy it's there, but we all would rather it not be there.</div><div><br><=
/div><div>Only this time, the ambiguity is discovered before the feature be=
came standard. So... why are we still doing it that way?</div><div><br></di=
v><div>In fact, looking over P0595, it's actually negatively useful as =
a feature. It is only allowed to evaluate to "true" in cases wher=
e the expression is <i>required</i> to be a constant expression; it <i>must=
</i> evaluate to "false" in other cases, even if the compiler wan=
ts to run it at compile time. So you cannot use it for cases where there is=
a divergence between efficient the compile-time and runtime solutions.</di=
v><div><br></div><div>So what good is the feature at all?<br></div></div><s=
pan>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534%40isocpp.org</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">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/CAJsLGmqiFSA4xZieB8Y-1%2BLzXbZKvBtMpr=
r3W%3Deasf14rMB%2B0g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/CAJsLGmqiFSA4xZieB8Y-1%2BLzXbZKvBtMprr3W%3Dea=
sf14rMB%2B0g%40mail.gmail.com</a>.<br>
</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/CALmDwq2KqeoV-_KgtNo%3Dcg8bRxELsY3b4f=
8WxS9fDHjJMwe%3DVQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2KqeoV=
-_KgtNo%3Dcg8bRxELsY3b4f8WxS9fDHjJMwe%3DVQ%40mail.gmail.com</a>.<br />
--000000000000ca67ce0572d27e4b--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 7 Aug 2018 11:28:15 +0100
Raw View
--000000000000b51fab0572d5da2d
Content-Type: text/plain; charset="UTF-8"
On Tue, 7 Aug 2018 at 07:28, Nicolas Lesser <blitzrakete@gmail.com> wrote:
> Oh ok. Well, in that case, I would do:
>
> constexpr auto result = foo(/*args*/);
>
> so that foo is evaluated at compile-time. There's some talk about adding a
> constexpr compound statement, where everything in it would be constant
> evaluated so that would also solve your problem in a way (you might want to
> look into that).
>
Since lambdas are already constexpr by default in c++17 it seems to me that
the language already provides constexpr compound statements, no?
int main()
{
constexpr auto x = []
{
int a= 10;
a *= 2;
a = a + 5;
return a;
}();
return x;
}
>
> On Mon, Aug 6, 2018, 10:53 PM Dawid Pilarski <picppstandard@gmail.com>
> wrote:
>
>> @Nicolas Lesser
>>
>> What's the motivation for this?
>>>
>>
>> I will try to share with you my motivation.
>>
>> there can be some numerical computation done in the constexpr function.
>> For me it's important, that in some usages it will be compile time
>> evaluated, otherwise I cannot fulfill my agreement with the user regarding
>> performance.
>>
>> So now I want to call it
>>
>> //context
>> my_contexpr_function_here(/*args*/);
>> //context
>>
>> issues:
>> 1. There is no way of checking whether the function really got executed
>> in compile time,
>> 2. There is no way if informing the reader (instead of the comment) to
>> let him know that he must not break the compile-time evaluation of
>> constexpr function.
>>
>> So in my case after writing things down, to be sure, that function is
>> compile-time evaluated I needed to check the generated code.
>>
>> So, when I do:
>>
>> constexpr my_contexpr_function_here(/*args*/);
>>
>> when I do change in the code, I am sure, that if I break compile-time
>> evaluation I will get compile time error.
>>
>>
>> 2018-08-07 2:51 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:
>>
>>>
>>>
>>> On Monday, August 6, 2018 at 6:55:26 PM UTC-4, bastie...@gmail.com
>>> wrote:
>>>>
>>>>
>>>>
>>>> On Tuesday, August 7, 2018 at 12:41:51 AM UTC+2, Ville Voutilainen
>>>> wrote:
>>>>>
>>>>> On 7 August 2018 at 01:26, Arthur O'Dwyer <arthur....@gmail.com>
>>>>> wrote:
>>>>> > On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Voutilainen
>>>>> wrote:
>>>>> >>
>>>>> >> On 6 August 2018 at 23:23, Nicol Bolas <jmck...@gmail.com> wrote:
>>>>> >> > By contrast, there can be times when the non-constexpr version is
>>>>> the
>>>>> >> > same
>>>>> >> > as the constexpr one, except that maybe it does some file
>>>>> logging. So
>>>>> >> > doing
>>>>> >> > an `if constexpr(!is_constant_evaluated())` to surround such
>>>>> blocks is
>>>>> >> > perfectly valid.
>>>>> >>
>>>>> >> That condition is always false, so I don't know what you're getting
>>>>> at.
>>>>> >
>>>>> >
>>>>> > Yes you do.
>>>>> >
>>>>> >
>>>>> > There's an unfortunate tendency of several people in "constexpr"
>>>>> discussions
>>>>> > to treat the accidental behavior of
>>>>>
>>>>> That behavior is not accidental.
>>>>>
>>>>
>>>> Yes it's worse, it's confusing by design.
>>>>
>>>
>>> It's rather like the Most Vexing Parse. MVP is based on an unfortunate
>>> combination of the ambiguity between a possible function declaration and a
>>> variable declaration initialized via constructor-call syntax. We can all
>>> understand why it's there, but we all would rather it not be there.
>>>
>>> Only this time, the ambiguity is discovered before the feature became
>>> standard. So... why are we still doing it that way?
>>>
>>> In fact, looking over P0595, it's actually negatively useful as a
>>> feature. It is only allowed to evaluate to "true" in cases where the
>>> expression is *required* to be a constant expression; it *must*
>>> evaluate to "false" in other cases, even if the compiler wants to run it at
>>> compile time. So you cannot use it for cases where there is a divergence
>>> between efficient the compile-time and runtime solutions.
>>>
>>> So what good is the feature at all?
>>>
>>> --
>>> 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/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqiFSA4xZieB8Y-1%2BLzXbZKvBtMprr3W%3Deasf14rMB%2B0g%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqiFSA4xZieB8Y-1%2BLzXbZKvBtMprr3W%3Deasf14rMB%2B0g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2KqeoV-_KgtNo%3Dcg8bRxELsY3b4f8WxS9fDHjJMwe%3DVQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2KqeoV-_KgtNo%3Dcg8bRxELsY3b4f8WxS9fDHjJMwe%3DVQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ04v9EBi41Q4akCiEZH84F8VTmqz9dygxBuDn6HscFbg%40mail.gmail.com.
--000000000000b51fab0572d5da2d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, 7 Aug 2018 at 07:28, Nicolas Lesser <<a href=3D"mailto:blitzrakete@gma=
il.com">blitzrakete@gmail.com</a>> wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"auto"><div>Oh ok. Well, in that case, I would do:</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">constexpr auto result =3D f=
oo(/*args*/);</div><div dir=3D"auto"><br></div><div dir=3D"auto">so that fo=
o is evaluated at compile-time. There's some talk about adding a conste=
xpr compound statement, where everything in it would be constant evaluated =
so that would also solve your problem in a way (you might want to look into=
that).=C2=A0<br></div></div></blockquote><div><br></div><div>Since lambdas=
are already constexpr by default in c++17 it seems to me that the language=
already provides constexpr compound statements, no?</div><div><br></div><d=
iv><div style=3D"color:rgb(0,0,0);background-color:rgb(255,255,254)"><div><=
font face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">int</=
span> main()</font></div><div><font face=3D"monospace, monospace">{</font><=
/div><div> <font face=3D"monospace, monospace"><span style=3D"color:rgb(=
0,0,255)">=C2=A0 constexpr</span> <span style=3D"color:rgb(0,0,255)">auto</=
span> x =3D []</font></div><div><font face=3D"monospace, monospace">=C2=A0 =
{</font></div><div> <font face=3D"monospace, monospace"><span style=
=3D"color:rgb(0,0,255)">=C2=A0 =C2=A0 int</span> a=3D <span style=3D"color:=
rgb(9,136,90)">10</span>;</font></div><div><font face=3D"monospace, monospa=
ce">=C2=A0 =C2=A0 a *=3D <span style=3D"color:rgb(9,136,90)">2</span>;</fon=
t></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 a =3D a + <s=
pan style=3D"color:rgb(9,136,90)">5</span>;</font></div><div> <font =
face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)">=C2=A0 =C2=
=A0 return</span> a;</font></div><div><font face=3D"monospace, monospace">=
=C2=A0 }(); </font></div><font face=3D"monospace, monospace"><br></font><di=
v> <font face=3D"monospace, monospace"><span style=3D"color:rgb(0,0,255)=
">=C2=A0 return</span> x;</font></div><div><font face=3D"monospace, monospa=
ce">}</font></div><br></div></div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"auto"><div dir=3D"auto"><br><div class=3D"gmail_quote" d=
ir=3D"auto"><div dir=3D"ltr">On Mon, Aug 6, 2018, 10:53 PM Dawid Pilarski &=
lt;<a href=3D"mailto:picppstandard@gmail.com" target=3D"_blank">picppstanda=
rd@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">@Nicolas Lesser<br><br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><span style=3D"font-size:12.8px;background-color:rgb(255,255,255);t=
ext-decoration-style:initial;text-decoration-color:initial;float:none;displ=
ay:inline"><span>=C2=A0</span>What's the motivation for this?=C2=A0</sp=
an><br></blockquote><br>I will try to share with you my motivation.<div><br=
></div><div>there can be some numerical computation done in the constexpr f=
unction. For me it's important, that in some usages it will be compile =
time evaluated, otherwise I cannot fulfill my agreement with the user regar=
ding performance.<br><br>So now I want to call it=C2=A0<br><br>//context<br=
>my_contexpr_function_here(/*args*/);<br>//context</div><div><br>issues:<br=
>1. There is no way of checking whether the function really got executed in=
compile time,<br>2. There is no way if informing the reader (instead of th=
e comment) to let him know that he must not break the compile-time evaluati=
on of constexpr function.<br><br>So in my case after writing things down, t=
o be sure, that function is compile-time evaluated I needed to check the ge=
nerated code.<br><br>So, when I do:<br><br>constexpr <span style=3D"font-si=
ze:small;background-color:rgb(255,255,255);text-decoration-style:initial;te=
xt-decoration-color:initial;float:none;display:inline">my_contexpr_function=
_here(/*args*/);<br></span><br>when I do change in the code, I am sure, tha=
t if I break compile-time evaluation I will get compile time error.<br><br>=
</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2018-=
08-07 2:51 GMT+02:00 Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jm=
ckesson@gmail.com" rel=3D"noreferrer" target=3D"_blank">jmckesson@gmail.com=
</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span><=
br><br>On Monday, August 6, 2018 at 6:55:26 PM UTC-4, <a href=3D"mailto:bas=
tie...@gmail.com" rel=3D"noreferrer" target=3D"_blank">bastie...@gmail.com<=
/a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>=
On Tuesday, August 7, 2018 at 12:41:51 AM UTC+2, Ville Voutilainen wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex">On 7 August 2018 at 01:26, Arthur O&#=
39;Dwyer <<a rel=3D"nofollow noreferrer">arthur....@gmail.com</a>> wr=
ote:
<br>> On Monday, August 6, 2018 at 1:49:25 PM UTC-7, Ville Voutilainen w=
rote:
<br>>>
<br>>> On 6 August 2018 at 23:23, Nicol Bolas <<a rel=3D"noreferre=
r">jmck...@gmail.com</a>> wrote:
<br>>> > By contrast, there can be times when the non-constexpr ve=
rsion is the
<br>>> > same
<br>>> > as the constexpr one, except that maybe it does some file=
logging. So
<br>>> > doing
<br>>> > an `if constexpr(!is_constant_evaluated())` to surround s=
uch blocks is
<br>>> > perfectly valid.
<br>>>
<br>>> That condition is always false, so I don't know what you&#=
39;re getting at.
<br>>
<br>>
<br>> Yes you do.
<br>>
<br>>
<br>> There's an unfortunate tendency of several people in "con=
stexpr" discussions
<br>> to treat the accidental behavior of
<br>
<br>That behavior is not accidental.
<br></blockquote><div>=C2=A0</div><div>Yes it's worse, it's confusi=
ng by design.</div></div></blockquote><div><br></div></span><div>It's r=
ather like the Most Vexing Parse. MVP is based on an unfortunate combinatio=
n of the ambiguity between a possible function declaration and a variable d=
eclaration initialized via constructor-call syntax. We can all understand w=
hy it's there, but we all would rather it not be there.</div><div><br><=
/div><div>Only this time, the ambiguity is discovered before the feature be=
came standard. So... why are we still doing it that way?</div><div><br></di=
v><div>In fact, looking over P0595, it's actually negatively useful as =
a feature. It is only allowed to evaluate to "true" in cases wher=
e the expression is <i>required</i> to be a constant expression; it <i>must=
</i> evaluate to "false" in other cases, even if the compiler wan=
ts to run it at compile time. So you cannot use it for cases where there is=
a divergence between efficient the compile-time and runtime solutions.</di=
v><div><br></div><div>So what good is the feature at all?<br></div></div><s=
pan>
<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" rel=3D"nore=
ferrer" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer" target=3D"_blank">std-proposals@isocpp.org</a>.<br=
></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"noreferrer"=
target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/4c8c5f38-7e00-4b6a-a46a-c942e3e0a534%40isocpp.org</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" rel=3D"nore=
ferrer" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer" target=3D"_blank">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJsLGmqiFSA4xZieB8Y-1%2BLzXbZKvBtMpr=
r3W%3Deasf14rMB%2B0g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/CAJsLGmqiFSA4xZieB8Y-1%2BLzXbZKvBtMprr3W%3Dea=
sf14rMB%2B0g%40mail.gmail.com</a>.<br>
</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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq2KqeoV-_KgtNo%3Dcg8bRxELsY3b4f=
8WxS9fDHjJMwe%3DVQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CALmDwq2KqeoV-_KgtNo%3Dcg8bRxELsY3b4f8WxS9fDHjJMwe%3DVQ%40mail.gma=
il.com</a>.<br>
</blockquote></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/CALvx3hZ04v9EBi41Q4akCiEZH84F8VTmqz9d=
ygxBuDn6HscFbg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ04v9EBi41=
Q4akCiEZH84F8VTmqz9dygxBuDn6HscFbg%40mail.gmail.com</a>.<br />
--000000000000b51fab0572d5da2d--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 7 Aug 2018 08:18:31 -0700 (PDT)
Raw View
------=_Part_1909_1831941411.1533655111972
Content-Type: multipart/alternative;
boundary="----=_Part_1910_663787409.1533655111972"
------=_Part_1910_663787409.1533655111972
Content-Type: text/plain; charset="UTF-8"
On Tuesday, August 7, 2018 at 1:53:14 AM UTC-4, Dawid Pilarski wrote:
>
> @Nicolas Lesser
>
> What's the motivation for this?
>>
>
> I will try to share with you my motivation.
>
> there can be some numerical computation done in the constexpr function.
> For me it's important, that in some usages it will be compile time
> evaluated, otherwise I cannot fulfill my agreement with the user regarding
> performance.
>
> So now I want to call it
>
> //context
> my_contexpr_function_here(/*args*/);
> //context
>
> issues:
> 1. There is no way of checking whether the function really got executed in
> compile time,
> 2. There is no way if informing the reader (instead of the comment) to let
> him know that he must not break the compile-time evaluation of constexpr
> function.
>
`constexpr!` handles both of those. You cannot call a `constexpr!` function
with non-constexpr parameters, and the return value is always `constexpr`.
So in my case after writing things down, to be sure, that function is
> compile-time evaluated I needed to check the generated code.
>
`constexpr!` ensures that the function is compile-time evaluated.
--
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/cec89f51-0f39-462d-a3e7-00aa7348b0c9%40isocpp.org.
------=_Part_1910_663787409.1533655111972
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, August 7, 2018 at 1:53:14 AM UTC-4, Da=
wid Pilarski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">@Nicolas Lesser<br><br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><span style=3D"font-size:12.8px;background-color:rgb(255,255,255);float=
:none;display:inline"><span>=C2=A0</span>What's the motivation for this=
?=C2=A0</span><br></blockquote><br>I will try to share with you my motivati=
on.<div><br></div><div>there can be some numerical computation done in the =
constexpr function. For me it's important, that in some usages it will =
be compile time evaluated, otherwise I cannot fulfill my agreement with the=
user regarding performance.<br><br>So now I want to call it=C2=A0<br><br>/=
/context<br>my_contexpr_function_here(/*<wbr>args*/);<br>//context</div><di=
v><br>issues:<br>1. There is no way of checking whether the function really=
got executed in compile time,<br>2. There is no way if informing the reade=
r (instead of the comment) to let him know that he must not break the compi=
le-time evaluation of constexpr function.<br></div></div></blockquote><div>=
<br></div><div>`constexpr!` handles both of those. You cannot call a `const=
expr!` function with non-constexpr parameters, and the return value is alwa=
ys `constexpr`.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>So in my case after writing things down, to be =
sure, that function is compile-time evaluated I needed to check the generat=
ed code.<br></div></div></blockquote><div><br></div><div>`constexpr!` ensur=
es that the function is compile-time evaluated.</div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cec89f51-0f39-462d-a3e7-00aa7348b0c9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cec89f51-0f39-462d-a3e7-00aa7348b0c9=
%40isocpp.org</a>.<br />
------=_Part_1910_663787409.1533655111972--
------=_Part_1909_1831941411.1533655111972--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 7 Aug 2018 08:19:52 -0700 (PDT)
Raw View
------=_Part_1815_1777686060.1533655192730
Content-Type: multipart/alternative;
boundary="----=_Part_1816_1723720203.1533655192730"
------=_Part_1816_1723720203.1533655192730
Content-Type: text/plain; charset="UTF-8"
On Tuesday, August 7, 2018 at 1:41:17 AM UTC-4, Ville Voutilainen wrote:
>
> On 7 August 2018 at 03:51, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > In fact, looking over P0595, it's actually negatively useful as a
> feature.
> > It is only allowed to evaluate to "true" in cases where the expression
> is
> > required to be a constant expression; it must evaluate to "false" in
> other
> > cases, even if the compiler wants to run it at compile time. So you
> cannot
> > use it for cases where there is a divergence between efficient the
> > compile-time and runtime solutions.
> >
> > So what good is the feature at all?
>
> It gives you a portable result, as opposed to a result that depends on
> whether your implementation
> folds or not. Just use a normal if instead of if constexpr and it'll
> do what you want.
>
But that behavior is *not* "what I want".
Basically, there are 3 possibilities in C++: required compile-time,
implementation-dependent compile-time, and actual runtime. This tool only
allows us to distinguish between the first and the rest. What users *need*
is to distinguish the *last* from the rest. After all, that's why you guard
these blocks; they're for stuff that can't happen at compile-time/runtime,
regardless of how the compiler decides when to run which.
When exactly would I care about the difference between required
compile-time and implementation-dependent compile-time? If I'm doing
logging, which can't be done at compile time, I don't care *why* the
function is being run at compile-time; I just need to not do logging in
those cases.
--
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/47416cd4-4d0e-4818-937e-3cae3c5d91f7%40isocpp.org.
------=_Part_1816_1723720203.1533655192730
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, August 7, 2018 at 1:41:17 AM UTC-4, Vi=
lle Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 7 Aug=
ust 2018 at 03:51, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"f1krvVGKDgAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">jmck...@gmail.com</a>> wrote:
<br>> In fact, looking over P0595, it's actually negatively useful a=
s a feature.
<br>> It is only allowed to evaluate to "true" in cases where =
the expression is
<br>> required to be a constant expression; it must evaluate to "fa=
lse" in other
<br>> cases, even if the compiler wants to run it at compile time. So yo=
u cannot
<br>> use it for cases where there is a divergence between efficient the
<br>> compile-time and runtime solutions.
<br>>
<br>> So what good is the feature at all?
<br>
<br>It gives you a portable result, as opposed to a result that depends on
<br>whether your implementation
<br>folds or not. Just use a normal if instead of if constexpr and it'l=
l
<br>do what you want.
<br></blockquote><div><br></div><div>But that behavior is <i>not</i> "=
what I want". <br></div><div><br></div><div>Basically, there are 3 pos=
sibilities in C++: required compile-time,=20
implementation-dependent compile-time, and actual runtime. This tool=20
only allows us to distinguish between the first and the rest. What users
<i>need</i> is to distinguish the <i>last</i> from the rest. After all,
that's why you guard these blocks; they're for stuff that can'=
t happen=20
at compile-time/runtime, regardless of how the compiler decides when to=20
run which.</div><div><br></div><div>When exactly would I care about the dif=
ference between required compile-time and implementation-dependent compile-=
time? If I'm doing logging, which can't be done at compile time, I =
don't care <i>why</i> the function is being run at compile-time; I just=
need to not do logging in those cases.</div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/47416cd4-4d0e-4818-937e-3cae3c5d91f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/47416cd4-4d0e-4818-937e-3cae3c5d91f7=
%40isocpp.org</a>.<br />
------=_Part_1816_1723720203.1533655192730--
------=_Part_1815_1777686060.1533655192730--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 7 Aug 2018 16:24:02 -0700
Raw View
--0000000000002ac7560572e0b1e0
Content-Type: text/plain; charset="UTF-8"
On Tue, 7 Aug 2018 at 08:19, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, August 7, 2018 at 1:41:17 AM UTC-4, Ville Voutilainen wrote:
>>
>> On 7 August 2018 at 03:51, Nicol Bolas <jmck...@gmail.com> wrote:
>> > In fact, looking over P0595, it's actually negatively useful as a
>> feature.
>> > It is only allowed to evaluate to "true" in cases where the expression
>> is
>> > required to be a constant expression; it must evaluate to "false" in
>> other
>> > cases, even if the compiler wants to run it at compile time. So you
>> cannot
>> > use it for cases where there is a divergence between efficient the
>> > compile-time and runtime solutions.
>> >
>> > So what good is the feature at all?
>>
>> It gives you a portable result, as opposed to a result that depends on
>> whether your implementation
>> folds or not. Just use a normal if instead of if constexpr and it'll
>> do what you want.
>>
>
> But that behavior is *not* "what I want".
>
> Basically, there are 3 possibilities in C++: required compile-time,
> implementation-dependent compile-time, and actual runtime.
>
If I understand correctly, you're distinguishing between:
1) required compile-time
2a) not required compile-time, does not happen at runtime on the physical
machine (because it was simplified or removed during compilation)
2b) not required compile-time, actually happens at runtime on the physical
machine
Under the as-if rule, the difference between 2a and 2b is unobservable.
But there are other problems with this taxonomy. The big one is that
usually any given expression or statement is somewhere between 2a and 2b,
with some parts simplified or removed during compilation and other parts
actually executed. And I think you're also assuming that the compiler's
choice to move cases between 2a and 2b necessarily has something to do with
constant evaluation, which isn't really right. Constant evaluation happens
to just be one of the tools that some compilers choose to use to try to
move cases from 2b towards 2a -- but that's merely an implementation detail.
> This tool only allows us to distinguish between the first and the rest.
> What users *need* is to distinguish the *last* from the rest. After all,
> that's why you guard these blocks; they're for stuff that can't happen at
> compile-time/runtime, regardless of how the compiler decides when to run
> which.
>
> When exactly would I care about the difference between required
> compile-time and implementation-dependent compile-time? If I'm doing
> logging, which can't be done at compile time, I don't care *why* the
> function is being run at compile-time; I just need to not do logging in
> those cases.
>
What you're asking for is underspecified to the point that it's not
reasonable to evaluate its merits. Moving code from 2b to 2a isn't some
grandiose monolithic action; it's something that's potentially done
piecewise. For example, if you have some code that says
if (!nicol_bolas_is_constant_evaluated())
my_logger << "something something\n";
then is it your intent that the compiler is permitted to delete that
if-statement and still execute the surrounding code at runtime? If not, why
not? Does it matter if the logic inside the compiler that does this has
something to do with its constant expression evaluator or is in a different
piece of the compiler?
--
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/CAOfiQqkfyd%2BYQ2Zp0QXikrDMfaXqTEULM3D%3DkXDXgs7ZV90NFA%40mail.gmail.com.
--0000000000002ac7560572e0b1e0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 7 Aug =
2018 at 08:19, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com">jmcke=
sson@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">On Tuesday, August 7, 2018 at 1:41:17 AM UTC-4, Ville Voutilain=
en wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">On 7 August 2018 at 03:51,=
Nicol Bolas <<a rel=3D"nofollow">jmck...@gmail.com</a>> wrote:
<br>> In fact, looking over P0595, it's actually negatively useful a=
s a feature.
<br>> It is only allowed to evaluate to "true" in cases where =
the expression is
<br>> required to be a constant expression; it must evaluate to "fa=
lse" in other
<br>> cases, even if the compiler wants to run it at compile time. So yo=
u cannot
<br>> use it for cases where there is a divergence between efficient the
<br>> compile-time and runtime solutions.
<br>>
<br>> So what good is the feature at all?
<br>
<br>It gives you a portable result, as opposed to a result that depends on
<br>whether your implementation
<br>folds or not. Just use a normal if instead of if constexpr and it'l=
l
<br>do what you want.
<br></blockquote><div><br></div><div>But that behavior is <i>not</i> "=
what I want". <br></div><div><br></div><div>Basically, there are 3 pos=
sibilities in C++: required compile-time,=20
implementation-dependent compile-time, and actual runtime.</div></div></blo=
ckquote><div><br></div><div>If I understand correctly, you're distingui=
shing between:</div><div><br></div><div>1) required compile-time</div><div>=
2a) not required compile-time, does not happen at runtime on the physical m=
achine (because it was simplified or removed during compilation)</div><div>=
2b) not required compile-time, actually happens at runtime on the physical =
machine</div><div><br></div><div>Under the as-if rule, the difference betwe=
en 2a and 2b is unobservable.</div><div><br></div><div>But there are other =
problems with this taxonomy. The big one is that usually any given expressi=
on or statement is somewhere between 2a and 2b, with some parts simplified =
or removed during compilation and other parts actually executed. And I thin=
k you're also assuming that the compiler's choice to move cases bet=
ween 2a and 2b necessarily has something to do with constant evaluation, wh=
ich isn't really right. Constant evaluation happens to just be one of t=
he tools that some compilers choose to use to try to move cases from 2b tow=
ards 2a -- but that's merely an implementation detail.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>This tool=20
only allows us to distinguish between the first and the rest. What users
<i>need</i> is to distinguish the <i>last</i> from the rest. After all,
that's why you guard these blocks; they're for stuff that can'=
t happen=20
at compile-time/runtime, regardless of how the compiler decides when to=20
run which.</div><div><br></div><div>When exactly would I care about the dif=
ference between required compile-time and implementation-dependent compile-=
time? If I'm doing logging, which can't be done at compile time, I =
don't care <i>why</i> the function is being run at compile-time; I just=
need to not do logging in those cases.</div></div></blockquote><div><br></=
div><div>What you're asking for is underspecified to the point that it&=
#39;s not reasonable to evaluate its merits. Moving code from 2b to 2a isn&=
#39;t some grandiose monolithic action; it's something that's poten=
tially done piecewise. For example, if you have some code that says</div><d=
iv><br></div><div>if (!nicol_bolas_is_constant_evaluated())</div><div>=C2=
=A0 my_logger << "something something\n";</div><div><br></d=
iv><div>then is it your intent that the compiler is permitted to delete tha=
t if-statement and still execute the surrounding code at runtime? If not, w=
hy not? Does it matter if the logic inside the compiler that does this has =
something to do with its constant expression evaluator or is in a different=
piece of the compiler?</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/CAOfiQqkfyd%2BYQ2Zp0QXikrDMfaXqTEULM3=
D%3DkXDXgs7ZV90NFA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkfyd%2=
BYQ2Zp0QXikrDMfaXqTEULM3D%3DkXDXgs7ZV90NFA%40mail.gmail.com</a>.<br />
--0000000000002ac7560572e0b1e0--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Tue, 7 Aug 2018 17:09:23 -0700
Raw View
--000000000000b8e0770572e152c4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, Aug 7, 2018 at 4:24 PM, Richard Smith <richard@metafoo.co.uk> wrote=
:
> On Tue, 7 Aug 2018 at 08:19, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Tuesday, August 7, 2018 at 1:41:17 AM UTC-4, Ville Voutilainen wrote:
>>>
>>> On 7 August 2018 at 03:51, Nicol Bolas <jmck...@gmail.com> wrote:
>>> > In fact, looking over P0595, it's actually negatively useful as a
>>> feature.
>>> > It is only allowed to evaluate to "true" in cases where the expressio=
n
>>> is
>>> > required to be a constant expression; it must evaluate to "false" in
>>> other
>>> > cases, even if the compiler wants to run it at compile time. So you
>>> cannot
>>> > use it for cases where there is a divergence between efficient the
>>> > compile-time and runtime solutions.
>>> >
>>> > So what good is the feature at all?
>>>
>>> It gives you a portable result, as opposed to a result that depends on
>>> whether your implementation
>>> folds or not. Just use a normal if instead of if constexpr and it'll
>>> do what you want.
>>>
>>
>> But that behavior is *not* "what I want".
>>
>> Basically, there are 3 possibilities in C++: required compile-time,
>> implementation-dependent compile-time, and actual runtime.
>>
>
> If I understand correctly, you're distinguishing between:
>
> 1) required compile-time
> 2a) not required compile-time, does not happen at runtime on the physical
> machine (because it was simplified or removed during compilation)
> 2b) not required compile-time, actually happens at runtime on the physica=
l
> machine
>
> Under the as-if rule, the difference between 2a and 2b is unobservable.
>
> But there are other problems with this taxonomy. The big one is that
> usually any given expression or statement is somewhere between 2a and 2b,
> with some parts simplified or removed during compilation and other parts
> actually executed. And I think you're also assuming that the compiler's
> choice to move cases between 2a and 2b necessarily has something to do wi=
th
> constant evaluation, which isn't really right. Constant evaluation happen=
s
> to just be one of the tools that some compilers choose to use to try to
> move cases from 2b towards 2a -- but that's merely an implementation deta=
il.
>
>
>> This tool only allows us to distinguish between the first and the rest.
>> What users *need* is to distinguish the *last* from the rest. After all,
>> that's why you guard these blocks; they're for stuff that can't happen a=
t
>> compile-time/runtime, regardless of how the compiler decides when to run
>> which.
>>
>> When exactly would I care about the difference between required
>> compile-time and implementation-dependent compile-time? If I'm doing
>> logging, which can't be done at compile time, I don't care *why* the
>> function is being run at compile-time; I just need to not do logging in
>> those cases.
>>
>
> What you're asking for is underspecified to the point that it's not
> reasonable to evaluate its merits. Moving code from 2b to 2a isn't some
> grandiose monolithic action; it's something that's potentially done
> piecewise.
>
Sure, but we're *used* to talking about the constexpr-evaluation action on
a function-by-function basis. Otherwise, Richard, wouldn't all your
arguments apply just as well to explain why marking individual functions as
"constexpr" was a bad idea?
> For example, if you have some code that says
>
> if (!nicol_bolas_is_constant_evaluated())
> my_logger << "something something\n";
>
> then is it your intent that the compiler is permitted to delete that
> if-statement and still execute the surrounding code at runtime? If not, w=
hy
> not? Does it matter if the logic inside the compiler that does this has
> something to do with its constant expression evaluator or is in a differe=
nt
> piece of the compiler?
>
I would interpret that snippet as meaning, "If this function is being
inlined 'in a constexpr context', then don't do logging." Now, the *reason=
*
we don't want to do logging is because it wouldn't compile as 'constexpr',
because it calls non-constexpr functions to do the printing. So just a
plain old `if` isn't good enough; we actually need `if constexpr` to make
sure the compiler doesn't try to generate code for it =E2=80=94 so that the
functionality that's left in our function is all constexpr-friendly.
Or, in general, another reason we might want "if constexpr context" is so
that we can use different algorithms at runtime versus compile-time =E2=80=
=94 e.g.,
for performance reasons. See the example of "sqrt" worked out in
https://quuxplusone.github.io/blog/2018/06/12/perennial-impossibilities/#de=
tect-the-constexprness-of-the-current-context
If the compiler had to instantiate both branches, it seems like that would
tend to defeat the purpose.
Now, for a sufficiently smart compiler, there's a difference between
*instantiating* both branches (which increases compile time) and
*codegenning* both branches (which increases code size). Maybe that's what
saves us here: all compilers will be sufficiently smart and we'll get the
speed benefit on `sqrt` for only a mild compile-time hit. I'd like to see
an implementation, though.
(And yes, "constexpr context" is basically impossible to define. However, I
think we're all worried about the WG21 equivalent of the Politician's
Fallacy: "We must do something that is implementable =E2=80=94 this is
implementable =E2=80=94 therefore we must do this.")
(Sufficiently smart tooling could also solve the `if constexpr` problem, by
emitting a warning diagnostic any time `is_constexpr_evaluated()` was used
in a constant context. But tooling has not kept up with the pace of C++'s
syntactic pitfalls in general
<https://quuxplusone.github.io/blog/2018/04/09/long-long-long-is-too-long-f=
or-gcc/>,
so I'm reluctant to rely on it here.)
my $.02,
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0LVwWenedw7dVA27EHa-Lpb1s6H1-iOwqpFCSPdEqr=
3Ww%40mail.gmail.com.
--000000000000b8e0770572e152c4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Aug 7, 2018 at 4:24 PM, Richard Smith <span dir=3D=
"ltr"><<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richar=
d@metafoo.co.uk</a>></span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_q=
uote"><span class=3D"gmail-"><div dir=3D"ltr">On Tue, 7 Aug 2018 at 08:19, =
Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jm=
ckesson@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:=
solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
>On Tuesday, August 7, 2018 at 1:41:17 AM UTC-4, Ville Voutilainen wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex">On 7 August 2018 at 03:51, Nicol Bolas <<a rel=3D"nofollo=
w">jmck...@gmail.com</a>> wrote:
<br>> In fact, looking over P0595, it's actually negatively useful a=
s a feature.
<br>> It is only allowed to evaluate to "true" in cases where =
the expression is
<br>> required to be a constant expression; it must evaluate to "fa=
lse" in other
<br>> cases, even if the compiler wants to run it at compile time. So yo=
u cannot
<br>> use it for cases where there is a divergence between efficient the
<br>> compile-time and runtime solutions.
<br>>
<br>> So what good is the feature at all?
<br>
<br>It gives you a portable result, as opposed to a result that depends on
<br>whether your implementation
<br>folds or not. Just use a normal if instead of if constexpr and it'l=
l
<br>do what you want.
<br></blockquote><div><br></div><div>But that behavior is <i>not</i> "=
what I want". <br></div><div><br></div><div>Basically, there are 3 pos=
sibilities in C++: required compile-time,=20
implementation-dependent compile-time, and actual runtime.</div></div></blo=
ckquote><div><br></div></span><div>If I understand correctly, you're di=
stinguishing between:</div><div><br></div><div>1) required compile-time</di=
v><div>2a) not required compile-time, does not happen at runtime on the phy=
sical machine (because it was simplified or removed during compilation)</di=
v><div>2b) not required compile-time, actually happens at runtime on the ph=
ysical machine</div><div><br></div><div>Under the as-if rule, the differenc=
e between 2a and 2b is unobservable.</div><div><br></div><div>But there are=
other problems with this taxonomy. The big one is that usually any given e=
xpression or statement is somewhere between 2a and 2b, with some parts simp=
lified or removed during compilation and other parts actually executed. And=
I think you're also assuming that the compiler's choice to move ca=
ses between 2a and 2b necessarily has something to do with constant evaluat=
ion, which isn't really right. Constant evaluation happens to just be o=
ne of the tools that some compilers choose to use to try to move cases from=
2b towards 2a -- but that's merely an implementation detail.</div><spa=
n class=3D"gmail-"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
This tool=20
only allows us to distinguish between the first and the rest. What users
<i>need</i> is to distinguish the <i>last</i> from the rest. After all,
that's why you guard these blocks; they're for stuff that can'=
t happen=20
at compile-time/runtime, regardless of how the compiler decides when to=20
run which.</div><div><br></div><div>When exactly would I care about the dif=
ference between required compile-time and implementation-dependent compile-=
time? If I'm doing logging, which can't be done at compile time, I =
don't care <i>why</i> the function is being run at compile-time; I just=
need to not do logging in those cases.</div></div></blockquote><div><br></=
div></span><div>What you're asking for is underspecified to the point t=
hat it's not reasonable to evaluate its merits. Moving code from 2b to =
2a isn't some grandiose monolithic action; it's something that'=
s potentially done piecewise.</div></div></div></blockquote><div><br></div>=
<div>Sure, but we're <i>used</i> to talking about the constexpr-evaluat=
ion action on a function-by-function basis. Otherwise, Richard, wouldn'=
t all your arguments apply just as well to explain why marking individual f=
unctions as "constexpr" was a bad idea?</div><div><br></div><div>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote=
"><div> For example, if you have some code that says</div><div><br></div><d=
iv>if (!nicol_bolas_is_constant_<wbr>evaluated())</div><div>=C2=A0 my_logge=
r << "something something\n";</div><div><br></div><div>then=
is it your intent that the compiler is permitted to delete that if-stateme=
nt and still execute the surrounding code at runtime? If not, why not? Does=
it matter if the logic inside the compiler that does this has something to=
do with its constant expression evaluator or is in a different piece of th=
e compiler?</div></div></div></blockquote><div><br></div><div>I would inter=
pret that snippet as meaning, "If this function is being inlined '=
in a constexpr context', then don't do logging." =C2=A0Now, th=
e <i>reason</i> we don't want to do logging is because it wouldn't =
compile as 'constexpr', because it calls non-constexpr functions to=
do the printing. So just a plain old `if` isn't good enough; we actual=
ly need `if constexpr` to make sure the compiler doesn't try to generat=
e code for it =E2=80=94 so that the functionality that's left in our fu=
nction is all constexpr-friendly.</div><div><br></div><div>Or, in general, =
another reason we might want "if constexpr context" is so that we=
can use different algorithms at runtime versus compile-time =E2=80=94 e.g.=
, for performance reasons.=C2=A0 See the example of "sqrt" worked=
out in=C2=A0<a href=3D"https://quuxplusone.github.io/blog/2018/06/12/peren=
nial-impossibilities/#detect-the-constexprness-of-the-current-context">http=
s://quuxplusone.github.io/blog/2018/06/12/perennial-impossibilities/#detect=
-the-constexprness-of-the-current-context</a>=C2=A0 If the compiler had to =
instantiate both branches, it seems like that would tend to defeat the purp=
ose.</div><div><br></div><div>Now, for a sufficiently smart compiler, there=
's a difference between <i>instantiating</i> both branches (which incre=
ases compile time) and <i>codegenning</i> both branches (which increases co=
de size). Maybe that's what saves us here: all compilers will be suffic=
iently smart and we'll get the speed benefit on `sqrt` for only a mild =
compile-time hit. I'd like to see an implementation, though.</div><div>=
<br></div><div>(And yes, "constexpr context" is basically impossi=
ble to define. However, I think we're all worried about the WG21 equiva=
lent of the Politician's Fallacy: "We must do something that is im=
plementable =E2=80=94 this is implementable =E2=80=94 therefore we must do =
this.")</div><div><br></div><div><div>(Sufficiently smart tooling coul=
d also solve the `if constexpr` problem, by emitting a warning diagnostic a=
ny time `is_constexpr_evaluated()` was used in a constant context. But=C2=
=A0<a href=3D"https://quuxplusone.github.io/blog/2018/04/09/long-long-long-=
is-too-long-for-gcc/">tooling has not kept up with the pace of C++'s sy=
ntactic pitfalls in general</a>, so I'm reluctant to rely on it here.)<=
/div></div><div><br></div><div>my $.02,</div><div>=E2=80=93Arthur</div></di=
v></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/CADvuK0LVwWenedw7dVA27EHa-Lpb1s6H1-iO=
wqpFCSPdEqr3Ww%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0LVwWenedw7=
dVA27EHa-Lpb1s6H1-iOwqpFCSPdEqr3Ww%40mail.gmail.com</a>.<br />
--000000000000b8e0770572e152c4--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Tue, 7 Aug 2018 18:13:01 -0700 (PDT)
Raw View
------=_Part_2006_760874573.1533690781261
Content-Type: multipart/alternative;
boundary="----=_Part_2007_1337736522.1533690781261"
------=_Part_2007_1337736522.1533690781261
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
>
> Or, in general, another reason we might want "if constexpr context" is so=
=20
> that we can use different algorithms at runtime versus compile-time =E2=
=80=94 e.g.,=20
> for performance reasons. See the example of "sqrt" worked out in=20
> https://quuxplusone.github.io/blog/2018/06/12/perennial-impossibilities/#=
detect-the-constexprness-of-the-current-context=20
> <https://www.google.com/url?q=3Dhttps%3A%2F%2Fquuxplusone.github.io%2Fblo=
g%2F2018%2F06%2F12%2Fperennial-impossibilities%2F%23detect-the-constexprnes=
s-of-the-current-context&sa=3DD&sntz=3D1&usg=3DAFQjCNE1h9wjzWkuQWiY1pzAuiY5=
OcTEUQ> =20
> If the compiler had to instantiate both branches, it seems like that woul=
d=20
> tend to defeat the purpose.=20
>
> Now, for a sufficiently smart compiler, there's a difference between=20
> *instantiating* both branches (which increases compile time) and=20
> *codegenning* both branches (which increases code size). Maybe that's=20
> what saves us here: all compilers will be sufficiently smart and we'll ge=
t=20
> the speed benefit on `sqrt` for only a mild compile-time hit. I'd like to=
=20
> see an implementation, though.
>
> (And yes, "constexpr context" is basically impossible to define. However,=
=20
> I think we're all worried about the WG21 equivalent of the Politician's=
=20
> Fallacy: "We must do something that is implementable =E2=80=94 this is=20
> implementable =E2=80=94 therefore we must do this.")
>
There's a definition for "required to be constant-evaluated" in p0595r1.=20
Are there any cases that you think that doesn't cover?=20
The example in the blog, sqrt, isn't a template, so there isn't any=20
instantiating going on at all. Even if a hypothetical "if constexpr=20
(std::is_constant_evaluated())" actually behaved like "if=20
(std::is_constant_evaluated())" and not like "if constexpr (true)", the=20
only difference would be have to do with whether or not some of the names=
=20
are considered odr-used. Other than that, both branches would have to be=20
parsed and evaluated anyway.
It really does not make sense to use "if constexpr" here - we're not in a=
=20
template. "if constexpr" isn't about like... branch performance, it's about=
=20
conditional instantiation. Compilers are pretty good about turning if=20
(false) { ... } into no code.
>
--=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/c515063f-8366-4ba0-bb80-17e98c10c245%40isocpp.or=
g.
------=_Part_2007_1337736522.1533690781261
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D=
"gmail_quote"><div>Or, in general, another reason we might want "if co=
nstexpr context" is so that we can use different algorithms at runtime=
versus compile-time =E2=80=94 e.g., for performance reasons.=C2=A0 See the=
example of "sqrt" worked out in=C2=A0<a href=3D"https://www.goog=
le.com/url?q=3Dhttps%3A%2F%2Fquuxplusone.github.io%2Fblog%2F2018%2F06%2F12%=
2Fperennial-impossibilities%2F%23detect-the-constexprness-of-the-current-co=
ntext&sa=3DD&sntz=3D1&usg=3DAFQjCNE1h9wjzWkuQWiY1pzAuiY5OcTEUQ"=
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https:/=
/www.google.com/url?q\x3dhttps%3A%2F%2Fquuxplusone.github.io%2Fblog%2F2018%=
2F06%2F12%2Fperennial-impossibilities%2F%23detect-the-constexprness-of-the-=
current-context\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1h9wjzWkuQWiY1pzAu=
iY5OcTEUQ';return true;" onclick=3D"this.href=3D'https://www.google=
..com/url?q\x3dhttps%3A%2F%2Fquuxplusone.github.io%2Fblog%2F2018%2F06%2F12%2=
Fperennial-impossibilities%2F%23detect-the-constexprness-of-the-current-con=
text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1h9wjzWkuQWiY1pzAuiY5OcTEUQ&#=
39;;return true;">https://quuxplusone.github.<wbr>io/blog/2018/06/12/perenn=
ial-<wbr>impossibilities/#detect-the-<wbr>constexprness-of-the-current-<wbr=
>context</a>=C2=A0 If the compiler had to instantiate both branches, it see=
ms like that would tend to defeat the purpose.=C2=A0</div></div></div></blo=
ckquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div =
class=3D"gmail_quote"><div></div><div><br></div><div>Now, for a sufficientl=
y smart compiler, there's a difference between <i>instantiating</i> bot=
h branches (which increases compile time) and <i>codegenning</i> both branc=
hes (which increases code size). Maybe that's what saves us here: all c=
ompilers will be sufficiently smart and we'll get the speed benefit on =
`sqrt` for only a mild compile-time hit. I'd like to see an implementat=
ion, though.</div><div><br></div><div>(And yes, "constexpr context&quo=
t; is basically impossible to define. However, I think we're all worrie=
d about the WG21 equivalent of the Politician's Fallacy: "We must =
do something that is implementable =E2=80=94 this is implementable =E2=80=
=94 therefore we must do this.")</div></div></div></blockquote><div><b=
r></div><div>There's a definition for "required to be constant-eva=
luated" in p0595r1. Are there any cases that you think that doesn'=
t cover?=C2=A0</div><div><br></div><div>The example in the blog, sqrt, isn&=
#39;t a template, so there isn't any instantiating going on at all. Eve=
n if a hypothetical "if constexpr (std::is_constant_evaluated())"=
actually behaved like "if (std::is_constant_evaluated())" and no=
t like "if constexpr (true)", the only difference would be have t=
o do with whether or not some of the names are considered odr-used. Other t=
han that, both branches would have to be parsed and evaluated anyway.</div>=
<div><br></div><div>It really does not make sense to use "if constexpr=
" here - we're not in a template. "if constexpr" isn'=
;t about like... branch performance, it's about conditional instantiati=
on. Compilers are pretty good about turning if (false) { ... } into no code=
..</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote>
<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/c515063f-8366-4ba0-bb80-17e98c10c245%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c515063f-8366-4ba0-bb80-17e98c10c245=
%40isocpp.org</a>.<br />
------=_Part_2007_1337736522.1533690781261--
------=_Part_2006_760874573.1533690781261--
.
Author: Dawid Pilarski <picppstandard@gmail.com>
Date: Wed, 8 Aug 2018 07:45:06 +0200
Raw View
--0000000000004dd4570572e60392
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
@Nicol Bolas
> On Tuesday, August 7, 2018 at 1:53:14 AM UTC-4, Dawid Pilarski wrote:
> @Nicolas Lesser
>
> I will try to share with you my motivation.
> there can be some numerical computation done in the constexpr function.
> For me it's important, that in some usages it will be compile time
> evaluated, otherwise I cannot fulfill my agreement with the user regardin=
g
> performance.
> So now I want to call it
> //context
> my_contexpr_function_here(/*args*/);
> //context
> issues:
> 1. There is no way of checking whether the function really got executed i=
n
> compile time,
> 2. There is no way if informing the reader (instead of the comment) to le=
t
> him know that he must not break the compile-time evaluation of constexpr
> function.
> `constexpr!` handles both of those. You cannot call a `constexpr!`
> function with non-constexpr parameters, and the return value is always
> `constexpr`.
> So in my case after writing things down, to be sure, that function is
> compile-time evaluated I needed to check the generated code.
> `constexpr!` ensures that the function is compile-time evaluated.
That is true indeed and it's not what I worry about. Let's assume, that
`my_constexpr_function_here(/*args*/)` is actually constexpr!.
//context
my_contexpr_function_here(/*args*/); //must be compile time evaluated to
meet performance expectations
//context
//----- few files of code later ---/
//runtime-context
my_contexpr_function_here(/*runtime-args*/); //damn... is there any non
constexpr! version of this function? //note no such issue with regular
constxpr functions
//runtime-context
that scenario is fine then, but if user won't provide non constexpr!
version of calculation method, then user is stuck.
This is why I thought, that maybe it's better to provide some calling level
syntax to force evaluation of function in compile-time.
To sum up, what I want to say:
If there is a constexpr! function designed for non-type, but numerical
computations, then it can still be useful to call it in non-constexpr
contexts and developer (implementing the constexpr function)
might simply skip this opportunity, because it's easy to skip such things
if you forget about how users can use your library.
2018-08-08 3:13 GMT+02:00 Barry Revzin <barry.revzin@gmail.com>:
> Or, in general, another reason we might want "if constexpr context" is so
>> that we can use different algorithms at runtime versus compile-time =E2=
=80=94 e.g.,
>> for performance reasons. See the example of "sqrt" worked out in
>> https://quuxplusone.github.io/blog/2018/06/12/perennial-i
>> mpossibilities/#detect-the-constexprness-of-the-current-context
>> <https://www.google.com/url?q=3Dhttps%3A%2F%2Fquuxplusone.github.io%2Fbl=
og%2F2018%2F06%2F12%2Fperennial-impossibilities%2F%23detect-the-constexprne=
ss-of-the-current-context&sa=3DD&sntz=3D1&usg=3DAFQjCNE1h9wjzWkuQWiY1pzAuiY=
5OcTEUQ>
>> If the compiler had to instantiate both branches, it seems like that wou=
ld
>> tend to defeat the purpose.
>>
>
>> Now, for a sufficiently smart compiler, there's a difference between
>> *instantiating* both branches (which increases compile time) and
>> *codegenning* both branches (which increases code size). Maybe that's
>> what saves us here: all compilers will be sufficiently smart and we'll g=
et
>> the speed benefit on `sqrt` for only a mild compile-time hit. I'd like t=
o
>> see an implementation, though.
>>
>> (And yes, "constexpr context" is basically impossible to define. However=
,
>> I think we're all worried about the WG21 equivalent of the Politician's
>> Fallacy: "We must do something that is implementable =E2=80=94 this is
>> implementable =E2=80=94 therefore we must do this.")
>>
>
> There's a definition for "required to be constant-evaluated" in p0595r1.
> Are there any cases that you think that doesn't cover?
>
> The example in the blog, sqrt, isn't a template, so there isn't any
> instantiating going on at all. Even if a hypothetical "if constexpr
> (std::is_constant_evaluated())" actually behaved like "if
> (std::is_constant_evaluated())" and not like "if constexpr (true)", the
> only difference would be have to do with whether or not some of the names
> are considered odr-used. Other than that, both branches would have to be
> parsed and evaluated anyway.
>
> It really does not make sense to use "if constexpr" here - we're not in a
> template. "if constexpr" isn't about like... branch performance, it's abo=
ut
> conditional instantiation. Compilers are pretty good about turning if
> (false) { ... } into no code.
>
>> --
> 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/c515063f-8366-4ba0-
> bb80-17e98c10c245%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c515063f-83=
66-4ba0-bb80-17e98c10c245%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAJsLGmrDgCR7Ra7map6RhcjxnUV2OGQfZVM5OvE8so9Fjon=
2fg%40mail.gmail.com.
--0000000000004dd4570572e60392
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">@Nicol Bolas<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"><span class=3D"gmail-im" style=3D"color:rgb(80,0,80);font-size:12.8=
px;text-decoration-style:initial;text-decoration-color:initial">On Tuesday,=
August 7, 2018 at 1:53:14 AM UTC-4, Dawid Pilarski wrote:<br></span>@Nicol=
as Lesser<br><br>I will try to share with you my motivation.<br>there can b=
e some numerical computation done in the constexpr function. For me it'=
s important, that in some usages it will be compile time evaluated, otherwi=
se I cannot fulfill my agreement with the user regarding performance.<br>So=
now I want to call it=C2=A0<br>//context<br>my_contexpr_function_here(/*ar=
<wbr>gs*/);<br>//context<br>issues:<br>1. There is no way of checking wheth=
er the function really got executed in compile time,<br>2. There is no way =
if informing the reader (instead of the comment) to let him know that he mu=
st not break the compile-time evaluation of constexpr function.<br>`constex=
pr!` handles both of those. You cannot call a `constexpr!` function with no=
n-constexpr parameters, and the return value is always `constexpr`.<br>So i=
n my case after writing things down, to be sure, that function is compile-t=
ime evaluated I needed to check the generated code.<br>`constexpr!` ensures=
that the function is compile-time evaluated.</blockquote><br><div>That is =
true indeed and it's not what I worry about. Let's assume, that `my=
_constexpr_function_here(/*<span style=3D"font-size:small;background-color:=
rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initia=
l;float:none;display:inline">args</span>*/)` is actually constexpr!.</div><=
div><br></div><div><span style=3D"font-size:small;background-color:rgb(255,=
255,255);text-decoration-style:initial;text-decoration-color:initial;float:=
none;display:inline">//context</span><br style=3D"font-size:small;backgroun=
d-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-colo=
r:initial"><span style=3D"font-size:small;background-color:rgb(255,255,255)=
;text-decoration-style:initial;text-decoration-color:initial;float:none;dis=
play:inline">my_contexpr_function_here(/*ar</span><wbr style=3D"font-size:s=
mall;background-color:rgb(255,255,255);text-decoration-style:initial;text-d=
ecoration-color:initial"><span style=3D"font-size:small;background-color:rg=
b(255,255,255);text-decoration-style:initial;text-decoration-color:initial;=
float:none;display:inline">gs*/); //must be compile time evaluated to meet =
performance expectations</span><br style=3D"font-size:small;background-colo=
r:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:init=
ial"><span style=3D"font-size:small;background-color:rgb(255,255,255);text-=
decoration-style:initial;text-decoration-color:initial;float:none;display:i=
nline">//context<br><br>//----- few files of code later ---/<br>//runtime-c=
ontext<br><span style=3D"text-decoration-style:initial;text-decoration-colo=
r:initial;float:none;display:inline">my_contexpr_function_here(/*runtime-ar=
</span><wbr style=3D"text-decoration-style:initial;text-decoration-color:in=
itial"><span style=3D"text-decoration-style:initial;text-decoration-color:i=
nitial;float:none;display:inline">gs*/); //damn... is there any non constex=
pr! version of this function? //note no such issue with regular constxpr fu=
nctions</span></span></div><div><span style=3D"font-size:small;background-c=
olor:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:i=
nitial;float:none;display:inline"><span style=3D"text-decoration-style:init=
ial;text-decoration-color:initial;float:none;display:inline">//runtime-cont=
ext</span><br></span><br>that scenario is fine then, but if user won't =
provide non constexpr! version of calculation method, then user is stuck.<b=
r>This is why I thought, that maybe it's better to provide some calling=
level syntax to force evaluation of function in compile-time.<br><br>To su=
m up, what I want to say:<br><br>If there is a constexpr! function designed=
for non-type, but numerical computations, then it can still be useful to c=
all it in non-constexpr contexts and developer (implementing the constexpr =
function)<br>might simply skip this opportunity, because it's easy to s=
kip such things if you forget about how users can use your library.</div><d=
iv><br></div><div><br></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">2018-08-08 3:13 GMT+02:00 Barry Revzin <span dir=3D"ltr">&=
lt;<a href=3D"mailto:barry.revzin@gmail.com" target=3D"_blank">barry.revzin=
@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D=
""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_quote"><div>Or, in general, another reason we might want "if cons=
texpr context" is so that we can use different algorithms at runtime v=
ersus compile-time =E2=80=94 e.g., for performance reasons.=C2=A0 See the e=
xample of "sqrt" worked out in=C2=A0<a href=3D"https://www.google=
..com/url?q=3Dhttps%3A%2F%2Fquuxplusone.github.io%2Fblog%2F2018%2F06%2F12%2F=
perennial-impossibilities%2F%23detect-the-constexprness-of-the-current-cont=
ext&sa=3DD&sntz=3D1&usg=3DAFQjCNE1h9wjzWkuQWiY1pzAuiY5OcTEUQ" r=
el=3D"nofollow" target=3D"_blank">https://quuxplusone.github.<wbr>io/blog/2=
018/06/12/perennial-i<wbr>mpossibilities/#detect-the-con<wbr>stexprness-of-=
the-current-cont<wbr>ext</a>=C2=A0 If the compiler had to instantiate both =
branches, it seems like that would tend to defeat the purpose.=C2=A0</div><=
/div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div class=3D"gmail_quote"><div></div><div><br></div><div>Now, for a =
sufficiently smart compiler, there's a difference between <i>instantiat=
ing</i> both branches (which increases compile time) and <i>codegenning</i>=
both branches (which increases code size). Maybe that's what saves us =
here: all compilers will be sufficiently smart and we'll get the speed =
benefit on `sqrt` for only a mild compile-time hit. I'd like to see an =
implementation, though.</div><div><br></div><div>(And yes, "constexpr =
context" is basically impossible to define. However, I think we're=
all worried about the WG21 equivalent of the Politician's Fallacy: &qu=
ot;We must do something that is implementable =E2=80=94 this is implementab=
le =E2=80=94 therefore we must do this.")</div></div></div></blockquot=
e><div><br></div></span><div>There's a definition for "required to=
be constant-evaluated" in p0595r1. Are there any cases that you think=
that doesn't cover?=C2=A0</div><div><br></div><div>The example in the =
blog, sqrt, isn't a template, so there isn't any instantiating goin=
g on at all. Even if a hypothetical "if constexpr (std::is_constant_ev=
aluated())<wbr>" actually behaved like "if (std::is_constant_eval=
uated())<wbr>" and not like "if constexpr (true)", the only =
difference would be have to do with whether or not some of the names are co=
nsidered odr-used. Other than that, both branches would have to be parsed a=
nd evaluated anyway.</div><div><br></div><div>It really does not make sense=
to use "if constexpr" here - we're not in a template. "=
if constexpr" isn't about like... branch performance, it's abo=
ut conditional instantiation. Compilers are pretty good about turning if (f=
alse) { ... } into no code.</div><span class=3D""><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
</blockquote>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c515063f-8366-4ba0-bb80-17e98c10c245%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/c515=
063f-8366-4ba0-<wbr>bb80-17e98c10c245%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJsLGmrDgCR7Ra7map6RhcjxnUV2OGQfZVM5=
OvE8so9Fjon2fg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJsLGmrDgCR7Ra7m=
ap6RhcjxnUV2OGQfZVM5OvE8so9Fjon2fg%40mail.gmail.com</a>.<br />
--0000000000004dd4570572e60392--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 8 Aug 2018 11:34:29 -0700 (PDT)
Raw View
------=_Part_53_377928187.1533753269929
Content-Type: multipart/alternative;
boundary="----=_Part_54_1407261557.1533753269930"
------=_Part_54_1407261557.1533753269930
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, August 7, 2018 at 8:09:26 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Tue, Aug 7, 2018 at 4:24 PM, Richard Smith <ric...@metafoo.co.uk=20
> <javascript:>> wrote:
>
>> On Tue, 7 Aug 2018 at 08:19, Nicol Bolas <jmck...@gmail.com <javascript:=
>>=20
>> wrote:
>>
>>> On Tuesday, August 7, 2018 at 1:41:17 AM UTC-4, Ville Voutilainen wrote=
:
>>>>
>>>> On 7 August 2018 at 03:51, Nicol Bolas <jmck...@gmail.com> wrote:=20
>>>> > In fact, looking over P0595, it's actually negatively useful as a=20
>>>> feature.=20
>>>> > It is only allowed to evaluate to "true" in cases where the=20
>>>> expression is=20
>>>> > required to be a constant expression; it must evaluate to "false" in=
=20
>>>> other=20
>>>> > cases, even if the compiler wants to run it at compile time. So you=
=20
>>>> cannot=20
>>>> > use it for cases where there is a divergence between efficient the=
=20
>>>> > compile-time and runtime solutions.=20
>>>> >=20
>>>> > So what good is the feature at all?=20
>>>>
>>>> It gives you a portable result, as opposed to a result that depends on=
=20
>>>> whether your implementation=20
>>>> folds or not. Just use a normal if instead of if constexpr and it'll=
=20
>>>> do what you want.=20
>>>>
>>>
>>> But that behavior is *not* "what I want".=20
>>>
>>> Basically, there are 3 possibilities in C++: required compile-time,=20
>>> implementation-dependent compile-time, and actual runtime.
>>>
>>
>> If I understand correctly, you're distinguishing between:
>>
>> 1) required compile-time
>> 2a) not required compile-time, does not happen at runtime on the physica=
l=20
>> machine (because it was simplified or removed during compilation)
>> 2b) not required compile-time, actually happens at runtime on the=20
>> physical machine
>>
>> Under the as-if rule, the difference between 2a and 2b is unobservable.
>>
>> But there are other problems with this taxonomy. The big one is that=20
>> usually any given expression or statement is somewhere between 2a and 2b=
,=20
>> with some parts simplified or removed during compilation and other parts=
=20
>> actually executed. And I think you're also assuming that the compiler's=
=20
>> choice to move cases between 2a and 2b necessarily has something to do w=
ith=20
>> constant evaluation, which isn't really right. Constant evaluation happe=
ns=20
>> to just be one of the tools that some compilers choose to use to try to=
=20
>> move cases from 2b towards 2a -- but that's merely an implementation det=
ail.
>> =20
>>
>>> This tool only allows us to distinguish between the first and the rest.=
=20
>>> What users *need* is to distinguish the *last* from the rest. After=20
>>> all, that's why you guard these blocks; they're for stuff that can't ha=
ppen=20
>>> at compile-time/runtime, regardless of how the compiler decides when to=
run=20
>>> which.
>>>
>>> When exactly would I care about the difference between required=20
>>> compile-time and implementation-dependent compile-time? If I'm doing=20
>>> logging, which can't be done at compile time, I don't care *why* the=20
>>> function is being run at compile-time; I just need to not do logging in=
=20
>>> those cases.
>>>
>>
>> What you're asking for is underspecified to the point that it's not=20
>> reasonable to evaluate its merits. Moving code from 2b to 2a isn't some=
=20
>> grandiose monolithic action; it's something that's potentially done=20
>> piecewise.
>>
>
> Sure, but we're *used* to talking about the constexpr-evaluation action=
=20
> on a function-by-function basis. Otherwise, Richard, wouldn't all your=20
> arguments apply just as well to explain why marking individual functions =
as=20
> "constexpr" was a bad idea?
>
> =20
>
>> For example, if you have some code that says
>>
>> if (!nicol_bolas_is_constant_evaluated())
>> my_logger << "something something\n";
>>
>> then is it your intent that the compiler is permitted to delete that=20
>> if-statement and still execute the surrounding code at runtime? If not, =
why=20
>> not? Does it matter if the logic inside the compiler that does this has=
=20
>> something to do with its constant expression evaluator or is in a differ=
ent=20
>> piece of the compiler?
>>
>
> I would interpret that snippet as meaning, "If this function is being=20
> inlined 'in a constexpr context', then don't do logging." Now, the=20
> *reason* we don't want to do logging is because it wouldn't compile as=20
> 'constexpr', because it calls non-constexpr functions to do the printing.=
=20
> So just a plain old `if` isn't good enough; we actually need `if constexp=
r`=20
> to make sure the compiler doesn't try to generate code for it =E2=80=94 s=
o that the=20
> functionality that's left in our function is all constexpr-friendly.
>
> Or, in general, another reason we might want "if constexpr context" is so=
=20
> that we can use different algorithms at runtime versus compile-time =E2=
=80=94 e.g.,=20
> for performance reasons. See the example of "sqrt" worked out in=20
> https://quuxplusone.github.io/blog/2018/06/12/perennial-impossibilities/#=
detect-the-constexprness-of-the-current-context =20
> If the compiler had to instantiate both branches, it seems like that woul=
d=20
> tend to defeat the purpose.
>
> Now, for a sufficiently smart compiler, there's a difference between=20
> *instantiating* both branches (which increases compile time) and=20
> *codegenning* both branches (which increases code size). Maybe that's=20
> what saves us here: all compilers will be sufficiently smart and we'll ge=
t=20
> the speed benefit on `sqrt` for only a mild compile-time hit. I'd like to=
=20
> see an implementation, though.
>
> (And yes, "constexpr context" is basically impossible to define. However,=
=20
> I think we're all worried about the WG21 equivalent of the Politician's=
=20
> Fallacy: "We must do something that is implementable =E2=80=94 this is=20
> implementable =E2=80=94 therefore we must do this.")
>
I guess that's my main issue with that `is_constexpr_context` proposal: is=
=20
it solving a useful problem? What exactly is the code that a user needs to=
=20
protect from required compile-time evaluation that would not also need=20
protection from implementation-determined compile-time evaluation?
All of the examples given in the proposal are so abstract that they're=20
meaningless. So what are the real-world examples of code where such=20
determination is genuinely useful?
Because we have cases where distinguishing between compile-time evaluation=
=20
of any kind and runtime evaluation is useful. Things like using compiler=20
intrinsics or inline assembly to do low-level things like sqrt and so=20
forth. We want to be able to make such functions `constexpr`-callable, but=
=20
the body of the `constexpr` version cannot use compiler intrinsics=20
(presumably) or inline assembly. So you would condition which function gets=
=20
called based on whether it is being evaluated at compile time.
It should also be noted that the `constexpr!` proposal doesn't talk about=
=20
overloading. That is, there's nothing about what happens if you have two=20
function declarations that differ only on the basis of `constexpr!`. So it=
=20
doesn't seem to allow you to have two function bodies with the same name,=
=20
such that the compiler will call one at compile-time and the other at=20
runtime, based on how it gets used.
So even P1073 doesn't really give us this power.
--=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/2a7c1640-da15-4d88-b146-e867461f17f9%40isocpp.or=
g.
------=_Part_54_1407261557.1533753269930
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 7, 2018 at 8:09:26 PM UTC-4, Arthur O&#=
39;Dwyer 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=
">On Tue, Aug 7, 2018 at 4:24 PM, Richard Smith <span dir=3D"ltr"><<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"5e5Xr1N3DAAJ"=
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;">ric...@met=
afoo.co.uk</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><span><div dir=3D"ltr=
">On Tue, 7 Aug 2018 at 08:19, Nicol Bolas <<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"5e5Xr1N3DAAJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.h=
ref=3D'javascript:';return true;">jmck...@gmail.com</a>> wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr">On Tuesday, August 7, 2018 at 1:=
41:17 AM UTC-4, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;border-left-color:rgb(204,204,204);padding-left:1ex">On 7 August 2018 a=
t 03:51, Nicol Bolas <<a rel=3D"nofollow">jmck...@gmail.com</a>> wrot=
e:
<br>> In fact, looking over P0595, it's actually negatively useful a=
s a feature.
<br>> It is only allowed to evaluate to "true" in cases where =
the expression is
<br>> required to be a constant expression; it must evaluate to "fa=
lse" in other
<br>> cases, even if the compiler wants to run it at compile time. So yo=
u cannot
<br>> use it for cases where there is a divergence between efficient the
<br>> compile-time and runtime solutions.
<br>>
<br>> So what good is the feature at all?
<br>
<br>It gives you a portable result, as opposed to a result that depends on
<br>whether your implementation
<br>folds or not. Just use a normal if instead of if constexpr and it'l=
l
<br>do what you want.
<br></blockquote><div><br></div><div>But that behavior is <i>not</i> "=
what I want". <br></div><div><br></div><div>Basically, there are 3 pos=
sibilities in C++: required compile-time,=20
implementation-dependent compile-time, and actual runtime.</div></div></blo=
ckquote><div><br></div></span><div>If I understand correctly, you're di=
stinguishing between:</div><div><br></div><div>1) required compile-time</di=
v><div>2a) not required compile-time, does not happen at runtime on the phy=
sical machine (because it was simplified or removed during compilation)</di=
v><div>2b) not required compile-time, actually happens at runtime on the ph=
ysical machine</div><div><br></div><div>Under the as-if rule, the differenc=
e between 2a and 2b is unobservable.</div><div><br></div><div>But there are=
other problems with this taxonomy. The big one is that usually any given e=
xpression or statement is somewhere between 2a and 2b, with some parts simp=
lified or removed during compilation and other parts actually executed. And=
I think you're also assuming that the compiler's choice to move ca=
ses between 2a and 2b necessarily has something to do with constant evaluat=
ion, which isn't really right. Constant evaluation happens to just be o=
ne of the tools that some compilers choose to use to try to move cases from=
2b towards 2a -- but that's merely an implementation detail.</div><spa=
n><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>This tool=20
only allows us to distinguish between the first and the rest. What users
<i>need</i> is to distinguish the <i>last</i> from the rest. After all,
that's why you guard these blocks; they're for stuff that can'=
t happen=20
at compile-time/runtime, regardless of how the compiler decides when to=20
run which.</div><div><br></div><div>When exactly would I care about the dif=
ference between required compile-time and implementation-dependent compile-=
time? If I'm doing logging, which can't be done at compile time, I =
don't care <i>why</i> the function is being run at compile-time; I just=
need to not do logging in those cases.</div></div></blockquote><div><br></=
div></span><div>What you're asking for is underspecified to the point t=
hat it's not reasonable to evaluate its merits. Moving code from 2b to =
2a isn't some grandiose monolithic action; it's something that'=
s potentially done piecewise.</div></div></div></blockquote><div><br></div>=
<div>Sure, but we're <i>used</i> to talking about the constexpr-evaluat=
ion action on a function-by-function basis. Otherwise, Richard, wouldn'=
t all your arguments apply just as well to explain why marking individual f=
unctions as "constexpr" was a bad idea?</div><div><br></div><div>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote=
"><div> For example, if you have some code that says</div><div><br></div><d=
iv>if (!nicol_bolas_is_constant_<wbr>evaluated())</div><div>=C2=A0 my_logge=
r << "something something\n";</div><div><br></div><div>then=
is it your intent that the compiler is permitted to delete that if-stateme=
nt and still execute the surrounding code at runtime? If not, why not? Does=
it matter if the logic inside the compiler that does this has something to=
do with its constant expression evaluator or is in a different piece of th=
e compiler?</div></div></div></blockquote><div><br></div><div>I would inter=
pret that snippet as meaning, "If this function is being inlined '=
in a constexpr context', then don't do logging." =C2=A0Now, th=
e <i>reason</i> we don't want to do logging is because it wouldn't =
compile as 'constexpr', because it calls non-constexpr functions to=
do the printing. So just a plain old `if` isn't good enough; we actual=
ly need `if constexpr` to make sure the compiler doesn't try to generat=
e code for it =E2=80=94 so that the functionality that's left in our fu=
nction is all constexpr-friendly.</div><div><br></div><div>Or, in general, =
another reason we might want "if constexpr context" is so that we=
can use different algorithms at runtime versus compile-time =E2=80=94 e.g.=
, for performance reasons.=C2=A0 See the example of "sqrt" worked=
out in=C2=A0<a href=3D"https://quuxplusone.github.io/blog/2018/06/12/peren=
nial-impossibilities/#detect-the-constexprness-of-the-current-context" targ=
et=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.=
google.com/url?q\x3dhttps%3A%2F%2Fquuxplusone.github.io%2Fblog%2F2018%2F06%=
2F12%2Fperennial-impossibilities%2F%23detect-the-constexprness-of-the-curre=
nt-context\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1h9wjzWkuQWiY1pzAuiY5Oc=
TEUQ';return true;" onclick=3D"this.href=3D'https://www.google.com/=
url?q\x3dhttps%3A%2F%2Fquuxplusone.github.io%2Fblog%2F2018%2F06%2F12%2Fpere=
nnial-impossibilities%2F%23detect-the-constexprness-of-the-current-context\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1h9wjzWkuQWiY1pzAuiY5OcTEUQ';r=
eturn true;">https://quuxplusone.github.<wbr>io/blog/2018/06/12/perennial-<=
wbr>impossibilities/#detect-the-<wbr>constexprness-of-the-current-<wbr>cont=
ext</a>=C2=A0 If the compiler had to instantiate both branches, it seems li=
ke that would tend to defeat the purpose.</div><div><br></div><div>Now, for=
a sufficiently smart compiler, there's a difference between <i>instant=
iating</i> both branches (which increases compile time) and <i>codegenning<=
/i> both branches (which increases code size). Maybe that's what saves =
us here: all compilers will be sufficiently smart and we'll get the spe=
ed benefit on `sqrt` for only a mild compile-time hit. I'd like to see =
an implementation, though.</div><div><br></div><div>(And yes, "constex=
pr context" is basically impossible to define. However, I think we'=
;re all worried about the WG21 equivalent of the Politician's Fallacy: =
"We must do something that is implementable =E2=80=94 this is implemen=
table =E2=80=94 therefore we must do this.")</div></div></div></div></=
blockquote><div><br></div><div>I guess that's my main issue with that `=
is_constexpr_context` proposal: is it solving a useful problem? What exactl=
y is the code that a user needs to protect from required compile-time evalu=
ation that would not also need protection from implementation-determined co=
mpile-time evaluation?</div><div><br></div><div>All of the examples given i=
n the proposal are so abstract that they're meaningless. So what are th=
e real-world examples of code where such determination is genuinely useful?=
</div><div><br></div><div>Because we have cases where distinguishing betwee=
n compile-time evaluation of any kind and runtime evaluation is useful. Thi=
ngs like using compiler intrinsics or inline assembly to do low-level thing=
s like sqrt and so forth. We want to be able to make such functions `conste=
xpr`-callable, but the body of the `constexpr` version cannot use compiler =
intrinsics (presumably) or inline assembly. So you would condition which fu=
nction gets called based on whether it is being evaluated at compile time.<=
/div><div><br></div><div>It should also be noted that the `constexpr!` prop=
osal doesn't talk about overloading. That is, there's nothing about=
what happens if you have two function declarations that differ only on the=
basis of `constexpr!`. So it doesn't seem to allow you to have two fun=
ction bodies with the same name, such that the compiler will call one at co=
mpile-time and the other at runtime, based on how it gets used.<br></div><d=
iv><br></div><div>So even P1073 doesn't really give us this power.</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/2a7c1640-da15-4d88-b146-e867461f17f9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2a7c1640-da15-4d88-b146-e867461f17f9=
%40isocpp.org</a>.<br />
------=_Part_54_1407261557.1533753269930--
------=_Part_53_377928187.1533753269929--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Wed, 8 Aug 2018 15:31:17 -0700 (PDT)
Raw View
------=_Part_98_327650091.1533767477736
Content-Type: multipart/alternative;
boundary="----=_Part_99_1800125951.1533767477736"
------=_Part_99_1800125951.1533767477736
Content-Type: text/plain; charset="UTF-8"
On Wednesday, August 8, 2018 at 1:34:30 PM UTC-5, Nicol Bolas wrote:
>
> I guess that's my main issue with that `is_constexpr_context` proposal: is
> it solving a useful problem? What exactly is the code that a user needs to
> protect from required compile-time evaluation that would not also need
> protection from implementation-determined compile-time evaluation?
>
> All of the examples given in the proposal are so abstract that they're
> meaningless. So what are the real-world examples of code where such
> determination is genuinely useful?
>
> Because we have cases where distinguishing between compile-time evaluation
> of any kind and runtime evaluation is useful. Things like using compiler
> intrinsics or inline assembly to do low-level things like sqrt and so
> forth. We want to be able to make such functions `constexpr`-callable, but
> the body of the `constexpr` version cannot use compiler intrinsics
> (presumably) or inline assembly. So you would condition which function gets
> called based on whether it is being evaluated at compile time.
>
It seems like you answered your question from your first paragraph in this
paragraph? That's exactly what is_constant_evaluated() is for - to do one
operation or the other (not which function gets called, but just what gets
run in the body). It's not just about compiler intrinsics and stuff either,
it's also to do something like... disable SSO when creating a std::string
so that we can have constexpr std::strings. They don't have to be different
functions, just in the body of the same function:
string::string(char const* p, size_t len) {
if (is_constant_evaluated() || len > whatever) {
_buffer = new char[len + 1];
// ...
} else {
// SSO stuff
}
}
>
> It should also be noted that the `constexpr!` proposal doesn't talk about
> overloading. That is, there's nothing about what happens if you have two
> function declarations that differ only on the basis of `constexpr!`. So it
> doesn't seem to allow you to have two function bodies with the same name,
> such that the compiler will call one at compile-time and the other at
> runtime, based on how it gets used.
>
> So even P1073 doesn't really give us this power.
>
It just doesn't work that way.
--
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/5e9dd642-2fb9-4714-93fa-bcbf8a9e470d%40isocpp.org.
------=_Part_99_1800125951.1533767477736
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, August 8, 2018 at 1:34:30 PM UTC-5, =
Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>I guess that's my main issue with that `is_constexpr_context`=
proposal: is it solving a useful problem? What exactly is the code that a =
user needs to protect from required compile-time evaluation that would not =
also need protection from implementation-determined compile-time evaluation=
?</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
dir=3D"ltr"><div></div><div><br></div><div>All of the examples given in th=
e proposal are so abstract that they're meaningless. So what are the re=
al-world examples of code where such determination is genuinely useful?</di=
v><div><br></div><div>Because we have cases where distinguishing between co=
mpile-time evaluation of any kind and runtime evaluation is useful. Things =
like using compiler intrinsics or inline assembly to do low-level things li=
ke sqrt and so forth. We want to be able to make such functions `constexpr`=
-callable, but the body of the `constexpr` version cannot use compiler intr=
insics (presumably) or inline assembly. So you would condition which functi=
on gets called based on whether it is being evaluated at compile time.</div=
></div></blockquote><div><br></div><div>It seems like you answered your que=
stion from your first paragraph in this paragraph? That's exactly what =
is_constant_evaluated() is for - to do one operation or the other (not whic=
h function gets called, but just what gets run in the body). It's not j=
ust about compiler intrinsics and stuff either, it's also to do somethi=
ng like... disable SSO when creating a std::string so that we can have cons=
texpr std::strings. They don't have to be different functions, just in =
the body of the same function:</div><div><br></div><div class=3D"prettyprin=
t" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">string</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">string</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">char</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
const</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> size_t len</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">is_constant_evaluated</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">||</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> len </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> whatever</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 _buffer </span><spa=
n 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"styled-by-prettify">new</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">char</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">len </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span s=
tyle=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 =C2=A0 =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// ...</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">else</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// SSO stuff</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><=
div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><br></div><div>It should also be noted that the `con=
stexpr!` proposal doesn't talk about overloading. That is, there's =
nothing about what happens if you have two function declarations that diffe=
r only on the basis of `constexpr!`. So it doesn't seem to allow you to=
have two function bodies with the same name, such that the compiler will c=
all one at compile-time and the other at runtime, based on how it gets used=
..</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
dir=3D"ltr"><div></div><div><br></div><div>So even P1073 doesn't reall=
y give us this power.</div></div></blockquote><div><br></div><div>It just d=
oesn't work that way.=C2=A0=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5e9dd642-2fb9-4714-93fa-bcbf8a9e470d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5e9dd642-2fb9-4714-93fa-bcbf8a9e470d=
%40isocpp.org</a>.<br />
------=_Part_99_1800125951.1533767477736--
------=_Part_98_327650091.1533767477736--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 8 Aug 2018 17:59:00 -0700 (PDT)
Raw View
------=_Part_112_579965514.1533776340393
Content-Type: multipart/alternative;
boundary="----=_Part_113_145200867.1533776340394"
------=_Part_113_145200867.1533776340394
Content-Type: text/plain; charset="UTF-8"
On Wednesday, August 8, 2018 at 6:31:17 PM UTC-4, Barry Revzin wrote:
>
> On Wednesday, August 8, 2018 at 1:34:30 PM UTC-5, Nicol Bolas wrote:
>>
>> I guess that's my main issue with that `is_constexpr_context` proposal:
>> is it solving a useful problem? What exactly is the code that a user needs
>> to protect from required compile-time evaluation that would not also need
>> protection from implementation-determined compile-time evaluation?
>>
>
>> All of the examples given in the proposal are so abstract that they're
>> meaningless. So what are the real-world examples of code where such
>> determination is genuinely useful?
>>
>> Because we have cases where distinguishing between compile-time
>> evaluation of any kind and runtime evaluation is useful. Things like using
>> compiler intrinsics or inline assembly to do low-level things like sqrt and
>> so forth. We want to be able to make such functions `constexpr`-callable,
>> but the body of the `constexpr` version cannot use compiler intrinsics
>> (presumably) or inline assembly. So you would condition which function gets
>> called based on whether it is being evaluated at compile time.
>>
>
> It seems like you answered your question from your first paragraph in this
> paragraph? That's exactly what is_constant_evaluated() is for - to do one
> operation or the other (not which function gets called, but just what gets
> run in the body). It's not just about compiler intrinsics and stuff either,
> it's also to do something like... disable SSO when creating a std::string
> so that we can have constexpr std::strings. They don't have to be different
> functions, just in the body of the same function:
>
> string::string(char const* p, size_t len) {
> if (is_constant_evaluated() || len > whatever) {
> _buffer = new char[len + 1];
> // ...
> } else {
> // SSO stuff
> }
> }
>
>
And what happens if the compiler *wants* to execute that at compile time in
a non-constant expression context? It can't, because "SSO stuff" can't be
executed at compile time. Whereas if `is_constant_evaluated` had returned
true during non-constexpr compile time execution, it could have worked.
It should also be noted that the `constexpr!` proposal doesn't talk about
>> overloading. That is, there's nothing about what happens if you have two
>> function declarations that differ only on the basis of `constexpr!`. So it
>> doesn't seem to allow you to have two function bodies with the same name,
>> such that the compiler will call one at compile-time and the other at
>> runtime, based on how it gets used.
>>
>
>> So even P1073 doesn't really give us this power.
>>
>
> It just doesn't work that way.
>
It doesn't work which way?
--
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/a95be702-a857-48de-89be-5578fc8fce32%40isocpp.org.
------=_Part_113_145200867.1533776340394
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, August 8, 2018 at 6:31:17 PM UTC-4, Barry Re=
vzin 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">On=
Wednesday, August 8, 2018 at 1:34:30 PM UTC-5, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I guess that's my =
main issue with that `is_constexpr_context` proposal: is it solving a usefu=
l problem? What exactly is the code that a user needs to protect from requi=
red compile-time evaluation that would not also need protection from implem=
entation-determined compile-time evaluation?</div></div></blockquote><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div><br></di=
v><div>All of the examples given in the proposal are so abstract that they&=
#39;re meaningless. So what are the real-world examples of code where such =
determination is genuinely useful?</div><div><br></div><div>Because we have=
cases where distinguishing between compile-time evaluation of any kind and=
runtime evaluation is useful. Things like using compiler intrinsics or inl=
ine assembly to do low-level things like sqrt and so forth. We want to be a=
ble to make such functions `constexpr`-callable, but the body of the `const=
expr` version cannot use compiler intrinsics (presumably) or inline assembl=
y. So you would condition which function gets called based on whether it is=
being evaluated at compile time.</div></div></blockquote><div><br></div><d=
iv>It seems like you answered your question from your first paragraph in th=
is paragraph? That's exactly what is_constant_evaluated() is for - to d=
o one operation or the other (not which function gets called, but just what=
gets run in the body). It's not just about compiler intrinsics and stu=
ff either, it's also to do something like... disable SSO when creating =
a std::string so that we can have constexpr std::strings. They don't ha=
ve to be different functions, just in the body of the same function:</div><=
div><br></div><div style=3D"background-color:rgb(250,250,250);border-color:=
rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word">=
<code><div><span style=3D"color:#008">string</span><span style=3D"color:#66=
0">::</span><span style=3D"color:#008">string</span><span style=3D"color:#6=
60">(</span><span style=3D"color:#008">char</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">const</span><span style=3D"color:#660"=
>*</span><span style=3D"color:#000"> p</span><span style=3D"color:#660">,</=
span><span style=3D"color:#000"> size_t len</span><span style=3D"color:#660=
">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</=
span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or:#008">if</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">(</span><span style=3D"color:#000">is_constant_evaluated</span><span s=
tyle=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">||</span><span style=3D"color:#000"> len </span><span style=
=3D"color:#660">></span><span style=3D"color:#000"> whatever</span><span=
style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 _buffer </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">new</span><span style=3D=
"color:#000"> </span><span style=3D"color:#008">char</span><span style=3D"c=
olor:#660">[</span><span style=3D"color:#000">len </span><span style=3D"col=
or:#660">+</span><span style=3D"color:#000"> </span><span style=3D"color:#0=
66">1</span><span style=3D"color:#660">];</span><span style=3D"color:#000">=
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#800">// ...</s=
pan><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"colo=
r:#660">}</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">else</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span>=
<span style=3D"color:#800">// SSO stuff</span><span style=3D"color:#000"><b=
r>=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</span><span style=3D"co=
lor:#000"><br></span><span style=3D"color:#660">}</span></div></code></div>=
<div><br></div></div></blockquote><div><br></div><div>And what happens if t=
he compiler <i>wants</i> to execute that at compile time in a non-constant =
expression context? It can't, because "SSO stuff" can't b=
e executed at compile time. Whereas if `is_constant_evaluated` had returned=
true during non-constexpr compile time execution, it could have worked.<br=
></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><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>It s=
hould also be noted that the `constexpr!` proposal doesn't talk about o=
verloading. That is, there's nothing about what happens if you have two=
function declarations that differ only on the basis of `constexpr!`. So it=
doesn't seem to allow you to have two function bodies with the same na=
me, such that the compiler will call one at compile-time and the other at r=
untime, based on how it gets used.</div></div></blockquote><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div><br></div><div>So =
even P1073 doesn't really give us this power.</div></div></blockquote><=
div><br></div><div>It just doesn't work that way.<br></div></div></bloc=
kquote><div><br></div><div>It doesn't work which way? <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/a95be702-a857-48de-89be-5578fc8fce32%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a95be702-a857-48de-89be-5578fc8fce32=
%40isocpp.org</a>.<br />
------=_Part_113_145200867.1533776340394--
------=_Part_112_579965514.1533776340393--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Thu, 9 Aug 2018 09:12:30 -0700 (PDT)
Raw View
------=_Part_397_732165097.1533831150355
Content-Type: multipart/alternative;
boundary="----=_Part_398_947774937.1533831150356"
------=_Part_398_947774937.1533831150356
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday, 8 August 2018 01:09:26 UTC+1, Arthur O'Dwyer wrote:
>
> On Tue, Aug 7, 2018 at 4:24 PM, Richard Smith <ric...@metafoo.co.uk=20
> <javascript:>> wrote:
>
>> On Tue, 7 Aug 2018 at 08:19, Nicol Bolas <jmck...@gmail.com <javascript:=
>>=20
>> wrote:
>>
>>> On Tuesday, August 7, 2018 at 1:41:17 AM UTC-4, Ville Voutilainen wrote=
:
>>>>
>>>> On 7 August 2018 at 03:51, Nicol Bolas <jmck...@gmail.com> wrote:=20
>>>> > In fact, looking over P0595, it's actually negatively useful as a=20
>>>> feature.=20
>>>> > It is only allowed to evaluate to "true" in cases where the=20
>>>> expression is=20
>>>> > required to be a constant expression; it must evaluate to "false" in=
=20
>>>> other=20
>>>> > cases, even if the compiler wants to run it at compile time. So you=
=20
>>>> cannot=20
>>>> > use it for cases where there is a divergence between efficient the=
=20
>>>> > compile-time and runtime solutions.=20
>>>> >=20
>>>> > So what good is the feature at all?=20
>>>>
>>>> It gives you a portable result, as opposed to a result that depends on=
=20
>>>> whether your implementation=20
>>>> folds or not. Just use a normal if instead of if constexpr and it'll=
=20
>>>> do what you want.=20
>>>>
>>>
>>> But that behavior is *not* "what I want".=20
>>>
>>> Basically, there are 3 possibilities in C++: required compile-time,=20
>>> implementation-dependent compile-time, and actual runtime.
>>>
>>
>> If I understand correctly, you're distinguishing between:
>>
>> 1) required compile-time
>> 2a) not required compile-time, does not happen at runtime on the physica=
l=20
>> machine (because it was simplified or removed during compilation)
>> 2b) not required compile-time, actually happens at runtime on the=20
>> physical machine
>>
>> Under the as-if rule, the difference between 2a and 2b is unobservable.
>>
>> But there are other problems with this taxonomy. The big one is that=20
>> usually any given expression or statement is somewhere between 2a and 2b=
,=20
>> with some parts simplified or removed during compilation and other parts=
=20
>> actually executed. And I think you're also assuming that the compiler's=
=20
>> choice to move cases between 2a and 2b necessarily has something to do w=
ith=20
>> constant evaluation, which isn't really right. Constant evaluation happe=
ns=20
>> to just be one of the tools that some compilers choose to use to try to=
=20
>> move cases from 2b towards 2a -- but that's merely an implementation det=
ail.
>> =20
>>
>>> This tool only allows us to distinguish between the first and the rest.=
=20
>>> What users *need* is to distinguish the *last* from the rest. After=20
>>> all, that's why you guard these blocks; they're for stuff that can't ha=
ppen=20
>>> at compile-time/runtime, regardless of how the compiler decides when to=
run=20
>>> which.
>>>
>>> When exactly would I care about the difference between required=20
>>> compile-time and implementation-dependent compile-time? If I'm doing=20
>>> logging, which can't be done at compile time, I don't care *why* the=20
>>> function is being run at compile-time; I just need to not do logging in=
=20
>>> those cases.
>>>
>>
>> What you're asking for is underspecified to the point that it's not=20
>> reasonable to evaluate its merits. Moving code from 2b to 2a isn't some=
=20
>> grandiose monolithic action; it's something that's potentially done=20
>> piecewise.
>>
>
> Sure, but we're *used* to talking about the constexpr-evaluation action=
=20
> on a function-by-function basis. Otherwise, Richard, wouldn't all your=20
> arguments apply just as well to explain why marking individual functions =
as=20
> "constexpr" was a bad idea?
>
> =20
>
>> For example, if you have some code that says
>>
>> if (!nicol_bolas_is_constant_evaluated())
>> my_logger << "something something\n";
>>
>> then is it your intent that the compiler is permitted to delete that=20
>> if-statement and still execute the surrounding code at runtime? If not, =
why=20
>> not? Does it matter if the logic inside the compiler that does this has=
=20
>> something to do with its constant expression evaluator or is in a differ=
ent=20
>> piece of the compiler?
>>
>
> I would interpret that snippet as meaning, "If this function is being=20
> inlined 'in a constexpr context', then don't do logging." Now, the=20
> *reason* we don't want to do logging is because it wouldn't compile as=20
> 'constexpr', because it calls non-constexpr functions to do the printing.=
=20
> So just a plain old `if` isn't good enough; we actually need `if constexp=
r`=20
> to make sure the compiler doesn't try to generate code for it =E2=80=94 s=
o that the=20
> functionality that's left in our function is all constexpr-friendly.
>
Huh? It's absolutely fine for a `constexpr` function to contain=20
constexpr-unfriendly code, as long as that code isn't *executed* when the=
=20
function is evaluated in a constexpr context.
#include <cstdlib>
constexpr int fib(int n) {
if (n < 0) std::abort();
if (n <=3D 1) return n;
return fib(n - 1) + fib(n - 2);
}
static_assert(fib(7) =3D=3D 13);
int f() { return fib(8); } // optimized to "return 21"
int g(int i) { return fib(i); }
A few constructs aren't allowed, such as asm, but that's easily worked=20
round with an IIFE.
Or, in general, another reason we might want "if constexpr context" is so=
=20
> that we can use different algorithms at runtime versus compile-time =E2=
=80=94 e.g.,=20
> for performance reasons. See the example of "sqrt" worked out in=20
> https://quuxplusone.github.io/blog/2018/06/12/perennial-impossibilities/#=
detect-the-constexprness-of-the-current-context =20
> If the compiler had to instantiate both branches, it seems like that woul=
d=20
> tend to defeat the purpose.
>
> Now, for a sufficiently smart compiler, there's a difference between=20
> *instantiating* both branches (which increases compile time) and=20
> *codegenning* both branches (which increases code size). Maybe that's=20
> what saves us here: all compilers will be sufficiently smart and we'll ge=
t=20
> the speed benefit on `sqrt` for only a mild compile-time hit. I'd like to=
=20
> see an implementation, though.
>
> (And yes, "constexpr context" is basically impossible to define. However,=
=20
> I think we're all worried about the WG21 equivalent of the Politician's=
=20
> Fallacy: "We must do something that is implementable =E2=80=94 this is=20
> implementable =E2=80=94 therefore we must do this.")
>
> (Sufficiently smart tooling could also solve the `if constexpr` problem,=
=20
> by emitting a warning diagnostic any time `is_constexpr_evaluated()` was=
=20
> used in a constant context. But tooling has not kept up with the pace of=
=20
> C++'s syntactic pitfalls in general=20
> <https://quuxplusone.github.io/blog/2018/04/09/long-long-long-is-too-long=
-for-gcc/>,=20
> so I'm reluctant to rely on it here.)
>
> my $.02,
> =E2=80=93Arthur
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/814b0b76-214f-4322-8a50-ad7a638a2cfd%40isocpp.or=
g.
------=_Part_398_947774937.1533831150356
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, 8 August 2018 01:09:26 UTC+1, Arthur O'D=
wyer 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">O=
n Tue, Aug 7, 2018 at 4:24 PM, Richard Smith <span dir=3D"ltr"><<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"5e5Xr1N3DAAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">ric...@metaf=
oo.co.uk</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><span><div dir=3D"ltr">=
On Tue, 7 Aug 2018 at 08:19, Nicol Bolas <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"5e5Xr1N3DAAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">jmck...@gmail.com</a>> wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr">On Tuesday, August 7, 2018 at 1:41=
:17 AM UTC-4, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex">On 7 August 2018 at =
03:51, Nicol Bolas <<a rel=3D"nofollow">jmck...@gmail.com</a>> wrote:
<br>> In fact, looking over P0595, it's actually negatively useful a=
s a feature.
<br>> It is only allowed to evaluate to "true" in cases where =
the expression is
<br>> required to be a constant expression; it must evaluate to "fa=
lse" in other
<br>> cases, even if the compiler wants to run it at compile time. So yo=
u cannot
<br>> use it for cases where there is a divergence between efficient the
<br>> compile-time and runtime solutions.
<br>>
<br>> So what good is the feature at all?
<br>
<br>It gives you a portable result, as opposed to a result that depends on
<br>whether your implementation
<br>folds or not. Just use a normal if instead of if constexpr and it'l=
l
<br>do what you want.
<br></blockquote><div><br></div><div>But that behavior is <i>not</i> "=
what I want". <br></div><div><br></div><div>Basically, there are 3 pos=
sibilities in C++: required compile-time,=20
implementation-dependent compile-time, and actual runtime.</div></div></blo=
ckquote><div><br></div></span><div>If I understand correctly, you're di=
stinguishing between:</div><div><br></div><div>1) required compile-time</di=
v><div>2a) not required compile-time, does not happen at runtime on the phy=
sical machine (because it was simplified or removed during compilation)</di=
v><div>2b) not required compile-time, actually happens at runtime on the ph=
ysical machine</div><div><br></div><div>Under the as-if rule, the differenc=
e between 2a and 2b is unobservable.</div><div><br></div><div>But there are=
other problems with this taxonomy. The big one is that usually any given e=
xpression or statement is somewhere between 2a and 2b, with some parts simp=
lified or removed during compilation and other parts actually executed. And=
I think you're also assuming that the compiler's choice to move ca=
ses between 2a and 2b necessarily has something to do with constant evaluat=
ion, which isn't really right. Constant evaluation happens to just be o=
ne of the tools that some compilers choose to use to try to move cases from=
2b towards 2a -- but that's merely an implementation detail.</div><spa=
n><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>This tool=20
only allows us to distinguish between the first and the rest. What users
<i>need</i> is to distinguish the <i>last</i> from the rest. After all,
that's why you guard these blocks; they're for stuff that can'=
t happen=20
at compile-time/runtime, regardless of how the compiler decides when to=20
run which.</div><div><br></div><div>When exactly would I care about the dif=
ference between required compile-time and implementation-dependent compile-=
time? If I'm doing logging, which can't be done at compile time, I =
don't care <i>why</i> the function is being run at compile-time; I just=
need to not do logging in those cases.</div></div></blockquote><div><br></=
div></span><div>What you're asking for is underspecified to the point t=
hat it's not reasonable to evaluate its merits. Moving code from 2b to =
2a isn't some grandiose monolithic action; it's something that'=
s potentially done piecewise.</div></div></div></blockquote><div><br></div>=
<div>Sure, but we're <i>used</i> to talking about the constexpr-evaluat=
ion action on a function-by-function basis. Otherwise, Richard, wouldn'=
t all your arguments apply just as well to explain why marking individual f=
unctions as "constexpr" was a bad idea?</div><div><br></div><div>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote=
"><div> For example, if you have some code that says</div><div><br></div><d=
iv>if (!nicol_bolas_is_constant_<wbr>evaluated())</div><div>=C2=A0 my_logge=
r << "something something\n";</div><div><br></div><div>then=
is it your intent that the compiler is permitted to delete that if-stateme=
nt and still execute the surrounding code at runtime? If not, why not? Does=
it matter if the logic inside the compiler that does this has something to=
do with its constant expression evaluator or is in a different piece of th=
e compiler?</div></div></div></blockquote><div><br></div><div>I would inter=
pret that snippet as meaning, "If this function is being inlined '=
in a constexpr context', then don't do logging." =C2=A0Now, th=
e <i>reason</i> we don't want to do logging is because it wouldn't =
compile as 'constexpr', because it calls non-constexpr functions to=
do the printing. So just a plain old `if` isn't good enough; we actual=
ly need `if constexpr` to make sure the compiler doesn't try to generat=
e code for it =E2=80=94 so that the functionality that's left in our fu=
nction is all constexpr-friendly.</div></div></div></div></blockquote><div>=
<br></div><div>Huh? It's absolutely fine for a `constexpr` function to =
contain constexpr-unfriendly code, as long as that code isn't *executed=
* when the function is evaluated in a constexpr context.</div><div><br></di=
v><div><div style=3D"color: #000000;background-color: #fffffe;font-family: =
Consolas, " liberation=3D"" mono",=3D"" courier,=3D"" monospace;font-weight=
:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"" 19px;white-space:=3D""=
pre;"=3D""><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-prettify">=
#include</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify"><cstdlib=
></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</s=
pan><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"> fib</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> n</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </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=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">n </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">abort</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">n </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: #066;" class=3D"styled-by-prettify"=
>1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> n</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br>=C2=A0</span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> fib</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">n </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">-</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> fib</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">n </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>-</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #066;" class=3D"styled-by-prettify">2</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">static_assert</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">fib</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">7=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
66;" class=3D"styled-by-prettify">13</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> fib</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"s=
tyled-by-prettify">8</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0</span><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">// optimized to &qu=
ot;return 21"</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> g</s=
pan><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"> i</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
fib</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">}</span></div></code></div><div><br></div>=
<div>A few constructs aren't allowed, such as asm, but that's easil=
y worked round with an IIFE.<br></div></div></div><div><br></div><blockquot=
e 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 class=3D"gmail_quo=
te"><div>Or, in general, another reason we might want "if constexpr co=
ntext" is so that we can use different algorithms at runtime versus co=
mpile-time =E2=80=94 e.g., for performance reasons.=C2=A0 See the example o=
f "sqrt" worked out in=C2=A0<a href=3D"https://quuxplusone.github=
..io/blog/2018/06/12/perennial-impossibilities/#detect-the-constexprness-of-=
the-current-context" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fquuxplusone.gith=
ub.io%2Fblog%2F2018%2F06%2F12%2Fperennial-impossibilities%2F%23detect-the-c=
onstexprness-of-the-current-context\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NE1h9wjzWkuQWiY1pzAuiY5OcTEUQ';return true;" onclick=3D"this.href=3D=
9;https://www.google.com/url?q\x3dhttps%3A%2F%2Fquuxplusone.github.io%2Fblo=
g%2F2018%2F06%2F12%2Fperennial-impossibilities%2F%23detect-the-constexprnes=
s-of-the-current-context\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1h9wjzWku=
QWiY1pzAuiY5OcTEUQ';return true;">https://quuxplusone.github.<wbr>io/bl=
og/2018/06/12/perennial-<wbr>impossibilities/#detect-the-<wbr>constexprness=
-of-the-current-<wbr>context</a>=C2=A0 If the compiler had to instantiate b=
oth branches, it seems like that would tend to defeat the purpose.<br></div=
><div><br></div><div>Now, for a sufficiently smart compiler, there's a =
difference between <i>instantiating</i> both branches (which increases comp=
ile time) and <i>codegenning</i> both branches (which increases code size).=
Maybe that's what saves us here: all compilers will be sufficiently sm=
art and we'll get the speed benefit on `sqrt` for only a mild compile-t=
ime hit. I'd like to see an implementation, though.</div><div><br></div=
><div>(And yes, "constexpr context" is basically impossible to de=
fine. However, I think we're all worried about the WG21 equivalent of t=
he Politician's Fallacy: "We must do something that is implementab=
le =E2=80=94 this is implementable =E2=80=94 therefore we must do this.&quo=
t;)</div><div><br></div><div><div>(Sufficiently smart tooling could also so=
lve the `if constexpr` problem, by emitting a warning diagnostic any time `=
is_constexpr_evaluated()` was used in a constant context. But=C2=A0<a href=
=3D"https://quuxplusone.github.io/blog/2018/04/09/long-long-long-is-too-lon=
g-for-gcc/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fquuxplusone.github.io%2Fb=
log%2F2018%2F04%2F09%2Flong-long-long-is-too-long-for-gcc%2F\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNE7XYSypS2-zQrVNwpDM4zlmbhv3g';return true;" o=
nclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fqu=
uxplusone.github.io%2Fblog%2F2018%2F04%2F09%2Flong-long-long-is-too-long-fo=
r-gcc%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE7XYSypS2-zQrVNwpDM4zlmbhv=
3g';return true;">tooling has not kept up with the pace of C++'s sy=
ntactic pitfalls in general</a>, so I'm reluctant to rely on it here.)<=
/div></div><div><br></div><div>my $.02,</div><div>=E2=80=93Arthur<br></div>=
</div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/814b0b76-214f-4322-8a50-ad7a638a2cfd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/814b0b76-214f-4322-8a50-ad7a638a2cfd=
%40isocpp.org</a>.<br />
------=_Part_398_947774937.1533831150356--
------=_Part_397_732165097.1533831150355--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 9 Aug 2018 19:31:21 +0300
Raw View
On 9 August 2018 at 03:59, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, August 8, 2018 at 6:31:17 PM UTC-4, Barry Revzin wrote:
>>
>> On Wednesday, August 8, 2018 at 1:34:30 PM UTC-5, Nicol Bolas wrote:
>>>
>>> I guess that's my main issue with that `is_constexpr_context` proposal:
>>> is it solving a useful problem? What exactly is the code that a user needs
>>> to protect from required compile-time evaluation that would not also need
>>> protection from implementation-determined compile-time evaluation?
>>>
>>>
>>> All of the examples given in the proposal are so abstract that they're
>>> meaningless. So what are the real-world examples of code where such
>>> determination is genuinely useful?
>>>
>>> Because we have cases where distinguishing between compile-time
>>> evaluation of any kind and runtime evaluation is useful. Things like using
>>> compiler intrinsics or inline assembly to do low-level things like sqrt and
>>> so forth. We want to be able to make such functions `constexpr`-callable,
>>> but the body of the `constexpr` version cannot use compiler intrinsics
>>> (presumably) or inline assembly. So you would condition which function gets
>>> called based on whether it is being evaluated at compile time.
>>
>>
>> It seems like you answered your question from your first paragraph in this
>> paragraph? That's exactly what is_constant_evaluated() is for - to do one
>> operation or the other (not which function gets called, but just what gets
>> run in the body). It's not just about compiler intrinsics and stuff either,
>> it's also to do something like... disable SSO when creating a std::string so
>> that we can have constexpr std::strings. They don't have to be different
>> functions, just in the body of the same function:
>>
>> string::string(char const* p, size_t len) {
>> if (is_constant_evaluated() || len > whatever) {
>> _buffer = new char[len + 1];
>> // ...
>> } else {
>> // SSO stuff
>> }
>> }
>>
>
> And what happens if the compiler wants to execute that at compile time in a
> non-constant expression context? It can't, because "SSO stuff" can't be
> executed at compile time. Whereas if `is_constant_evaluated` had returned
> true during non-constexpr compile time execution, it could have worked.
The compiler can execute and constant-fold whatever it likes under the
as-if rule. But
is_constant_evaluated and some sort of "is compiler trying to do
constant folding even though
it doesn't have to" are two very different
things. Just because a compiler is trying to do constant folding
doesn't mean it should pick
the code path chosen by the condition on is_constant_evaluated().
Furthermore, a compiler
doesn't have to fold anything if it's not compiling a constant
expression context. The
is_constant_evaluated() branch can have code in it that doesn't do
anything sane at
runtime (example of such code is invoking a compiler intrinsic that
allocates "compiler memory")
and vice versa, the run-time branch can have code in it that doesn't
do anything sane at
compile-time. The answer must be portable for such code to work, and
must not rely on
implementation QoI, which is what constant folding optimizations are.
If you want "are you trying to fold, mr. compiler?", feel free to
propose it separately.
--
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/CAFk2RUbycjY1K7wnss%3DE3RPJgOkML%2BP1qB3wk_sz1R%3DV5etL-g%40mail.gmail.com.
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Thu, 9 Aug 2018 09:37:55 -0700 (PDT)
Raw View
------=_Part_416_332937120.1533832675049
Content-Type: multipart/alternative;
boundary="----=_Part_417_1761215974.1533832675050"
------=_Part_417_1761215974.1533832675050
Content-Type: text/plain; charset="UTF-8"
On Thursday, 9 August 2018 01:59:00 UTC+1, Nicol Bolas wrote:
>
> On Wednesday, August 8, 2018 at 6:31:17 PM UTC-4, Barry Revzin wrote:
>>
>> On Wednesday, August 8, 2018 at 1:34:30 PM UTC-5, Nicol Bolas wrote:
>>>
>>> I guess that's my main issue with that `is_constexpr_context` proposal:
>>> is it solving a useful problem? What exactly is the code that a user needs
>>> to protect from required compile-time evaluation that would not also need
>>> protection from implementation-determined compile-time evaluation?
>>>
>>
>>> All of the examples given in the proposal are so abstract that they're
>>> meaningless. So what are the real-world examples of code where such
>>> determination is genuinely useful?
>>>
>>> Because we have cases where distinguishing between compile-time
>>> evaluation of any kind and runtime evaluation is useful. Things like using
>>> compiler intrinsics or inline assembly to do low-level things like sqrt and
>>> so forth. We want to be able to make such functions `constexpr`-callable,
>>> but the body of the `constexpr` version cannot use compiler intrinsics
>>> (presumably) or inline assembly. So you would condition which function gets
>>> called based on whether it is being evaluated at compile time.
>>>
>>
>> It seems like you answered your question from your first paragraph in
>> this paragraph? That's exactly what is_constant_evaluated() is for - to do
>> one operation or the other (not which function gets called, but just what
>> gets run in the body). It's not just about compiler intrinsics and stuff
>> either, it's also to do something like... disable SSO when creating a
>> std::string so that we can have constexpr std::strings. They don't have to
>> be different functions, just in the body of the same function:
>>
>> string::string(char const* p, size_t len) {
>> if (is_constant_evaluated() || len > whatever) {
>> _buffer = new char[len + 1];
>> // ...
>> } else {
>> // SSO stuff
>> }
>> }
>>
>>
> And what happens if the compiler *wants* to execute that at compile time
> in a non-constant expression context? It can't, because "SSO stuff" can't
> be executed at compile time. Whereas if `is_constant_evaluated` had
> returned true during non-constexpr compile time execution, it could have
> worked.
>
Well, that's not quite true. When the compiler is lifting code from runtime
to compile time, it's perfectly at liberty to execute UB and USB at compile
time that would be invalid in an actual constexpr context.
#include <cstring>
int n() {
float f = 5.0;
int i;
std::memcpy(&i, &f, sizeof(i));
return i; // optimizes to "return 1084227584"
}
It should also be noted that the `constexpr!` proposal doesn't talk about
>>> overloading. That is, there's nothing about what happens if you have two
>>> function declarations that differ only on the basis of `constexpr!`. So it
>>> doesn't seem to allow you to have two function bodies with the same name,
>>> such that the compiler will call one at compile-time and the other at
>>> runtime, based on how it gets used.
>>>
>>
>>> So even P1073 doesn't really give us this power.
>>>
>>
>> It just doesn't work that way.
>>
>
> It doesn't work which way?
>
--
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/a1228840-e40d-4411-9285-f9f238c454f7%40isocpp.org.
------=_Part_417_1761215974.1533832675050
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, 9 August 2018 01:59:00 UTC+1, Nicol B=
olas 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">O=
n Wednesday, August 8, 2018 at 6:31:17 PM UTC-4, Barry Revzin wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, August 8, 2=
018 at 1:34:30 PM UTC-5, Nicol Bolas wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>I guess that's my main issue with that `i=
s_constexpr_context` proposal: is it solving a useful problem? What exactly=
is the code that a user needs to protect from required compile-time evalua=
tion that would not also need protection from implementation-determined com=
pile-time evaluation?</div></div></blockquote><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div></div><div><br></div><div>All of the examp=
les given in the proposal are so abstract that they're meaningless. So =
what are the real-world examples of code where such determination is genuin=
ely useful?</div><div><br></div><div>Because we have cases where distinguis=
hing between compile-time evaluation of any kind and runtime evaluation is =
useful. Things like using compiler intrinsics or inline assembly to do low-=
level things like sqrt and so forth. We want to be able to make such functi=
ons `constexpr`-callable, but the body of the `constexpr` version cannot us=
e compiler intrinsics (presumably) or inline assembly. So you would conditi=
on which function gets called based on whether it is being evaluated at com=
pile time.</div></div></blockquote><div><br></div><div>It seems like you an=
swered your question from your first paragraph in this paragraph? That'=
s exactly what is_constant_evaluated() is for - to do one operation or the =
other (not which function gets called, but just what gets run in the body).=
It's not just about compiler intrinsics and stuff either, it's als=
o to do something like... disable SSO when creating a std::string so that w=
e can have constexpr std::strings. They don't have to be different func=
tions, just in the body of the same function:</div><div><br></div><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#008">string</span><span style=3D"color:#660">::</span><span styl=
e=3D"color:#008">string</span><span style=3D"color:#660">(</span><span styl=
e=3D"color:#008">char</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">const</span><span style=3D"color:#660">*</span><span style=
=3D"color:#000"> p</span><span style=3D"color:#660">,</span><span style=3D"=
color:#000"> size_t len</span><span style=3D"color:#660">)</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"=
color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">if</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#000">is_constant_evaluated</span><span style=3D"color:#660">=
()</span><span style=3D"color:#000"> </span><span style=3D"color:#660">||</=
span><span style=3D"color:#000"> len </span><span style=3D"color:#660">>=
</span><span style=3D"color:#000"> whatever</span><span style=3D"color:#660=
">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</=
span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 _buffer </s=
pan><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">new</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#008">char</span><span style=3D"color:#660">[</span><spa=
n style=3D"color:#000">len </span><span style=3D"color:#660">+</span><span =
style=3D"color:#000"> </span><span style=3D"color:#066">1</span><span style=
=3D"color:#660">];</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color:#800">// ...</span><span style=3D"co=
lor:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</span><span=
style=3D"color:#000"> </span><span style=3D"color:#008">else</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color=
:#800">// SSO stuff</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </sp=
an><span style=3D"color:#660">}</span><span style=3D"color:#000"><br></span=
><span style=3D"color:#660">}</span></div></code></div><div><br></div></div=
></blockquote><div><br></div><div>And what happens if the compiler <i>wants=
</i> to execute that at compile time in a non-constant expression context? =
It can't, because "SSO stuff" can't be executed at compil=
e time. Whereas if `is_constant_evaluated` had returned true during non-con=
stexpr compile time execution, it could have worked.<br></div></div></block=
quote><div><br></div><div>Well, that's not quite true. When the compile=
r is lifting code from runtime to compile time, it's perfectly at liber=
ty to execute UB and USB at compile time that would be invalid in an actual=
constexpr context.</div><div><br></div><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;"=
class=3D"styled-by-prettify">#include</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"s=
tyled-by-prettify"><cstring></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> n</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> f </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">5.0</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>=C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">memcpy</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(&</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">f</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">));</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">// optimizes to "return 1084227584"</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div><div><br><br></div>=
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><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>It =
should also be noted that the `constexpr!` proposal doesn't talk about =
overloading. That is, there's nothing about what happens if you have tw=
o function declarations that differ only on the basis of `constexpr!`. So i=
t doesn't seem to allow you to have two function bodies with the same n=
ame, such that the compiler will call one at compile-time and the other at =
runtime, based on how it gets used.</div></div></blockquote><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div><br></div><div>So=
even P1073 doesn't really give us this power.</div></div></blockquote>=
<div><br></div><div>It just doesn't work that way.<br></div></div></blo=
ckquote><div><br></div><div>It doesn't work which way? <br></div></div>=
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a1228840-e40d-4411-9285-f9f238c454f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a1228840-e40d-4411-9285-f9f238c454f7=
%40isocpp.org</a>.<br />
------=_Part_417_1761215974.1533832675050--
------=_Part_416_332937120.1533832675049--
.
Author: yakitori1010@gmail.com
Date: Sat, 11 Aug 2018 16:21:12 -0700 (PDT)
Raw View
------=_Part_1113_1084843207.1534029672591
Content-Type: multipart/alternative;
boundary="----=_Part_1114_675770917.1534029672591"
------=_Part_1114_675770917.1534029672591
Content-Type: text/plain; charset="UTF-8"
constexpr! is funcy object.
i think it is like high level preprocesser function without IO.
some peason hate preprocesser.
delete one mean from preprocesser.
it never has no meaning.
and...
it can hide the someone's secret.
maybe campany is needed??
i not have unhappiness for normal constexpr.
--
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/b8342808-126e-43f4-b5d6-7d0dbaa13713%40isocpp.org.
------=_Part_1114_675770917.1534029672591
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>constexpr! is funcy object.</div><div>i think it is l=
ike high level preprocesser function without IO.<br></div><div>some peason =
hate preprocesser.</div><div>delete one mean from preprocesser.</div><div>i=
t never has no meaning.</div><div><br></div><div>and...</div><div>it can hi=
de the someone's secret.</div><div>maybe campany is needed??</div><div>=
<br></div><div>i not have unhappiness for normal constexpr.</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/b8342808-126e-43f4-b5d6-7d0dbaa13713%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b8342808-126e-43f4-b5d6-7d0dbaa13713=
%40isocpp.org</a>.<br />
------=_Part_1114_675770917.1534029672591--
------=_Part_1113_1084843207.1534029672591--
.