------=_Part_514_1203327690.1487010694304
Content-Type: multipart/alternative;
 boundary="----=_Part_515_199080771.1487010694304"

------=_Part_515_199080771.1487010694304
Content-Type: text/plain; charset=UTF-8

Are there any existing efforts to create `constexpr` <cmath> functions, or
add the `constexpr` keyword to functions which already meet the criteria?

--
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/2f80ec0a-2dc2-46da-9f8c-d8026807cc1f%40isocpp.org.

------=_Part_515_199080771.1487010694304
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Are there any existing efforts to create `constexpr` &lt;c=
math&gt; functions, or add the `constexpr` keyword to functions which alrea=
dy meet the criteria?</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2f80ec0a-2dc2-46da-9f8c-d8026807cc1f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2f80ec0a-2dc2-46da-9f8c-d8026807cc1f=
%40isocpp.org</a>.<br />

------=_Part_515_199080771.1487010694304--

------=_Part_514_1203327690.1487010694304--

.

On 13 February 2017 at 20:31,  <nholthaus@gmail.com> wrote:
> Are there any existing efforts to create `constexpr` <cmath> functions, or
> add the `constexpr` keyword to functions which already meet the criteria?


We may need something like
http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0595r0.html
before we go there.

--
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/CAFk2RUZwHgUpwtPN%2BVr9bdL8OAmUGNG0RStzacYd1t%3Dgb0zK9g%40mail.gmail.com.

.

------=_Part_440_1762330714.1487011459059
Content-Type: multipart/alternative;
 boundary="----=_Part_441_383551467.1487011459059"

------=_Part_441_383551467.1487011459059
Content-Type: text/plain; charset=UTF-8

Is it just me, or should a compile-time static `if` be used to evaluate
whether you are in a `constexpr` context?

On Monday, February 13, 2017 at 1:33:22 PM UTC-5, Ville Voutilainen wrote:
>
> On 13 February 2017 at 20:31,  <nhol...@gmail.com <javascript:>> wrote:
> > Are there any existing efforts to create `constexpr` <cmath> functions,
> or
> > add the `constexpr` keyword to functions which already meet the
> criteria?
>
>
> We may need something like
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0595r0.html
> before we go there.
>

--
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/6b43a0e0-b99c-414d-bab9-38d3ce345e09%40isocpp.org.

------=_Part_441_383551467.1487011459059
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is it just me, or should a compile-time static=C2=A0`if` b=
e used to evaluate whether you are in a `constexpr` context?<br><br>On Mond=
ay, February 13, 2017 at 1:33:22 PM UTC-5, Ville Voutilainen wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On 13 February 2017 at 20:31, =C2=A0&l=
t;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:" ta=
rget=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"DMQNvtOQBAAJ">nho=
l...@gmail.com</a>&gt; wrote:
<br>&gt; Are there any existing efforts to create `constexpr` &lt;cmath&gt;=
 functions, or
<br>&gt; add the `constexpr` keyword to functions which already meet the cr=
iteria?
<br>
<br>
<br>We may need something like
<br><a onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%=
3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2017%2Fp0595r0.=
html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEfBVWQryz0Icm8stL_BgvC2jFWpQ&#=
39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2017%2Fp=
0595r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEfBVWQryz0Icm8stL_BgvC2=
jFWpQ&#39;;return true;" href=3D"http://open-std.org/JTC1/SC22/WG21/docs/pa=
pers/2017/p0595r0.html" target=3D"_blank" rel=3D"nofollow">http://open-std.=
org/JTC1/SC22/<wbr>WG21/docs/papers/2017/p0595r0.<wbr>html</a>
<br>before we go there.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6b43a0e0-b99c-414d-bab9-38d3ce345e09%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6b43a0e0-b99c-414d-bab9-38d3ce345e09=
%40isocpp.org</a>.<br />

------=_Part_441_383551467.1487011459059--

------=_Part_440_1762330714.1487011459059--

.

On 13 February 2017 at 20:44,  <nholthaus@gmail.com> wrote:
> Is it just me, or should a compile-time static `if` be used to evaluate
> whether you are in a `constexpr` context?

In an if constexpr, it would always return true with the proposal at
hand. The point of this query, as proposed, is not to drop a
non-instantiated
branch. However, I don't see such an idea as completely unfathomable;
it would require a different magic-function. The question
seems valid, though, and it should be asked when that proposal is reviewed.

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

.

--001a113d54fedefbb605486e1a81
Content-Type: text/plain; charset=UTF-8

I would really hate to see if constexpr(constexpr()) become the new
noexcept(noexcept(...)).

On Mon, Feb 13, 2017 at 1:00 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 13 February 2017 at 20:44,  <nholthaus@gmail.com> wrote:
> > Is it just me, or should a compile-time static `if` be used to evaluate
> > whether you are in a `constexpr` context?
>
> In an if constexpr, it would always return true with the proposal at
> hand. The point of this query, as proposed, is not to drop a
> non-instantiated
> branch. However, I don't see such an idea as completely unfathomable;
> it would require a different magic-function. The question
> seems valid, though, and it should be asked when that proposal is reviewed.
>
> --
> 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/CAFk2RUavh%2B7YYPDOj_
> VSSejis3JoTUSyfEdjEXAee8RiR0gPyQ%40mail.gmail.com.
>

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

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

<div dir=3D"ltr">I would really hate to see if constexpr(constexpr()) becom=
e the new noexcept(noexcept(...)).</div><div class=3D"gmail_extra"><br><div=
 class=3D"gmail_quote">On Mon, Feb 13, 2017 at 1:00 PM, Ville Voutilainen <=
span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=
=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><span class=3D"">On 13 February 2017 at 20:44,=C2=A0 &=
lt;<a href=3D"mailto:nholthaus@gmail.com">nholthaus@gmail.com</a>&gt; wrote=
:<br>
&gt; Is it just me, or should a compile-time static `if` be used to evaluat=
e<br>
&gt; whether you are in a `constexpr` context?<br>
<br>
</span>In an if constexpr, it would always return true with the proposal at=
<br>
hand. The point of this query, as proposed, is not to drop a<br>
non-instantiated<br>
branch. However, I don&#39;t see such an idea as completely unfathomable;<b=
r>
it would require a different magic-function. The question<br>
seems valid, though, and it should be asked when that proposal is reviewed.=
<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUavh%2B7YYPDOj_VSSejis3J=
oTUSyfEdjEXAee8RiR0gPyQ%40mail.gmail.com" rel=3D"noreferrer" target=3D"_bla=
nk">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/=
CAFk2RUavh%<wbr>2B7YYPDOj_<wbr>VSSejis3JoTUSyfEdjEXAee8RiR0gP<wbr>yQ%40mail=
..gmail.com</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeQyN1d0mNJNgAetrCxROwZeXuY6ew=
FfaDFobKVPzY3dww%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeQyN1d0=
mNJNgAetrCxROwZeXuY6ewFfaDFobKVPzY3dww%40mail.gmail.com</a>.<br />

--001a113d54fedefbb605486e1a81--

.

On Mon, Feb 13, 2017 at 12:31 PM,  <nholthaus@gmail.com> wrote:
> Are there any existing efforts to create `constexpr` <cmath> functions, or
> add the `constexpr` keyword to functions which already meet the criteria?

See http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0533r0.pdf

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
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/CAGsORuC3b6NCCcE9E2zEUxdKaFzhA5Mw-Jgzm6vCFDQpm3q%2Beg%40mail.gmail.com.

.

------=_Part_2349_519883671.1487143167531
Content-Type: multipart/alternative;
 boundary="----=_Part_2350_1708065841.1487143167531"

------=_Part_2350_1708065841.1487143167531
Content-Type: text/plain; charset=UTF-8

On Monday, February 13, 2017 at 10:03:39 PM UTC+3, Brent Friedman wrote:
>
> I would really hate to see if constexpr(constexpr()) become the new
> noexcept(noexcept(...)).
>

 Yes looks unattractive. But if it solves the longstanding problem with
constexpr functions in runtime I gasp for it! We can at last stop solving
problems like with string_view constructor using ad-hoc compiler magic.
stdlib writers can ask compiler writers for some special magic, other C++
programmers can't.

--
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/24321dbe-c0d1-45a9-9534-2d80649a28c2%40isocpp.org.

------=_Part_2350_1708065841.1487143167531
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, February 13, 2017 at 10:03:39 PM UTC+3, Brent F=
riedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>I would really hate to see if constexpr(constexpr()) become the new noexce=
pt(noexcept(...)).</div></blockquote><div><br>=C2=A0Yes looks unattractive.=
 But if it solves the longstanding problem with constexpr functions in runt=
ime I gasp for it! We can at last stop solving problems like with string_vi=
ew constructor using ad-hoc compiler magic. stdlib writers can ask compiler=
 writers for some special magic, other C++ programmers can&#39;t.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/24321dbe-c0d1-45a9-9534-2d80649a28c2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/24321dbe-c0d1-45a9-9534-2d80649a28c2=
%40isocpp.org</a>.<br />

------=_Part_2350_1708065841.1487143167531--

------=_Part_2349_519883671.1487143167531--

.

------=_Part_10943_1124588676.1487197607163
Content-Type: multipart/alternative;
 boundary="----=_Part_10944_2034028844.1487197607163"

------=_Part_10944_2034028844.1487197607163
Content-Type: text/plain; charset=UTF-8

I believe the outcome of the paper Ville mentions would be more on the line
of:

if (constexpr()) {}
else {}

if constexpr(constexpr()) would actually be meaningless, since 'if
constexpr' can only execute in a constexpr context, in which constexpr()
would always return true.

On Monday, February 13, 2017 at 11:03:39 AM UTC-8, Brent Friedman wrote:
>
> I would really hate to see if constexpr(constexpr()) become the new
> noexcept(noexcept(...)).
>
> On Mon, Feb 13, 2017 at 1:00 PM, Ville Voutilainen <ville.vo...@gmail.com
> <javascript:>> wrote:
>
>> On 13 February 2017 at 20:44,  <nhol...@gmail.com <javascript:>> wrote:
>> > Is it just me, or should a compile-time static `if` be used to evaluate
>> > whether you are in a `constexpr` context?
>>
>> In an if constexpr, it would always return true with the proposal at
>> hand. The point of this query, as proposed, is not to drop a
>> non-instantiated
>> branch. However, I don't see such an idea as completely unfathomable;
>> it would require a different magic-function. The question
>> seems valid, though, and it should be asked when that proposal is
>> reviewed.
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUavh%2B7YYPDOj_VSSejis3JoTUSyfEdjEXAee8RiR0gPyQ%40mail.gmail.com
>> .
>>
>
>

--
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/fb55dafd-207c-4841-8235-b8cfa61f13dd%40isocpp.org.

------=_Part_10944_2034028844.1487197607163
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I believe the outcome of the paper Ville mentions would be=
 more on the line of:<br><br>if (constexpr()) {}<br>else {}<br><br>if const=
expr(constexpr()) would actually be meaningless, since &#39;if constexpr&#3=
9; can only execute in a constexpr context, in which constexpr() would alwa=
ys return true.<br><br>On Monday, February 13, 2017 at 11:03:39 AM UTC-8, B=
rent Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">I would really hate to see if constexpr(constexpr()) become the ne=
w noexcept(noexcept(...)).</div><div><br><div class=3D"gmail_quote">On Mon,=
 Feb 13, 2017 at 1:00 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"A3jmuXqSBAAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">ville.vo...@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On=
 13 February 2017 at 20:44,=C2=A0 &lt;<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"A3jmuXqSBAAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#3=
9;javascript:&#39;;return true;">nhol...@gmail.com</a>&gt; wrote:<br>
&gt; Is it just me, or should a compile-time static `if` be used to evaluat=
e<br>
&gt; whether you are in a `constexpr` context?<br>
<br>
</span>In an if constexpr, it would always return true with the proposal at=
<br>
hand. The point of this query, as proposed, is not to drop a<br>
non-instantiated<br>
branch. However, I don&#39;t see such an idea as completely unfathomable;<b=
r>
it would require a different magic-function. The question<br>
seems valid, though, and it should be asked when that proposal is reviewed.=
<br>
<span><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
A3jmuXqSBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"A3jmuXqSBAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUavh%2B7YYPDOj_VSSejis3J=
oTUSyfEdjEXAee8RiR0gPyQ%40mail.gmail.com" rel=3D"nofollow" target=3D"_blank=
" onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/=
msgid/std-proposals/CAFk2RUavh%2B7YYPDOj_VSSejis3JoTUSyfEdjEXAee8RiR0gPyQ%4=
0mail.gmail.com&#39;;return true;" onclick=3D"this.href=3D&#39;https://grou=
ps.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUavh%2B7YYPDOj_VSSej=
is3JoTUSyfEdjEXAee8RiR0gPyQ%40mail.gmail.com&#39;;return true;">https://gro=
ups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAFk2RUavh%<wbr=
>2B7YYPDOj_<wbr>VSSejis3JoTUSyfEdjEXAee8RiR0gP<wbr>yQ%40mail.gmail.com</a>.=
<br>
</blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fb55dafd-207c-4841-8235-b8cfa61f13dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fb55dafd-207c-4841-8235-b8cfa61f13dd=
%40isocpp.org</a>.<br />

------=_Part_10944_2034028844.1487197607163--

------=_Part_10943_1124588676.1487197607163--

.

------=_Part_2443_1104087394.1487198807334
Content-Type: multipart/alternative;
 boundary="----=_Part_2444_2010726080.1487198807334"

------=_Part_2444_2010726080.1487198807334
Content-Type: text/plain; charset=UTF-8



On Wednesday, February 15, 2017 at 5:26:47 PM UTC-5, Erich Keane wrote:
>
> I believe the outcome of the paper Ville mentions would be more on the
> line of:
>
> if (constexpr()) {}
> else {}
>
> if constexpr(constexpr()) would actually be meaningless, since 'if
> constexpr' can only execute in a constexpr context, in which constexpr()
> would always return true.
>

But that wouldn't work. `constexpr` functions are forbidden from having
certain constructs: `asm` being the most relevant one here. So you could
never write this:

constexpr float sin(float i)
{
  if (constexpr())
  {
    //compile-time implementation.
  }
  else
  {
    asm { /* Runtime optimized assembly */ }
  }
}

A regular `if` statement cannot *eliminate* the code in the not-taken
branch, so this will still be a compile error. However, an `if constexpr`
statement already has all of the standards wording needed to expunge such
code.

As I've said elsewhere, the syntax should just be `if constexpr()`. The
only reason you would ever even need to ask the question of whether a
function is currently being executed at compile time is to be able to
discard non-`constexpr`-legal code. So you would only ever use the results
as part of an `if constexpr()` condition. So let's just cut out the
middleman and allow `if constexpr` to ask the question directly.

--
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/f07b2509-ab7a-45fb-bcc2-af00baccb410%40isocpp.org.

------=_Part_2444_2010726080.1487198807334
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, February 15, 2017 at 5:26:47 PM UTC-=
5, Erich Keane wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">I believe the outcome of the paper Ville mentions would be more on=
 the line of:<br><br>if (constexpr()) {}<br>else {}<br><br>if constexpr(con=
stexpr()) would actually be meaningless, since &#39;if constexpr&#39; can o=
nly execute in a constexpr context, in which constexpr() would always retur=
n true.<br></div></blockquote><div><br>But that wouldn&#39;t work. `constex=
pr` functions are forbidden from having certain constructs: `asm` being the=
 most relevant one here. So you could never write this:<br><br><div style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; overflow-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">float</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> sin</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</sp=
an><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: #008;" class=3D"styled-by-prettify">constexpr</span><span style=3D"c=
olor: #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: =
#660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">//compile-time implementation.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><s=
pan 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 styl=
e=3D"color: #008;" class=3D"styled-by-prettify">else</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">asm</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">/* Runtime optimized assembly */</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"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}<=
/span></div></code></div><br>A regular `if` statement cannot <i>eliminate</=
i> the code in the not-taken branch, so this will still be a compile error.=
 However, an `if constexpr` statement already has all of the standards word=
ing needed to expunge such code.</div><br>As I&#39;ve said elsewhere, the s=
yntax should just be `if constexpr()`. The only reason you would ever even =
need to ask the question of whether a function is currently being executed =
at compile time is to be able to discard non-`constexpr`-legal code. So you=
 would only ever use the results as part of an `if constexpr()` condition. =
So let&#39;s just cut out the middleman and allow `if constexpr` to ask the=
 question directly.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f07b2509-ab7a-45fb-bcc2-af00baccb410%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f07b2509-ab7a-45fb-bcc2-af00baccb410=
%40isocpp.org</a>.<br />

------=_Part_2444_2010726080.1487198807334--

------=_Part_2443_1104087394.1487198807334--

.

--f403045f56a41751d60548a2505a
Content-Type: text/plain; charset=UTF-8

Why cannot it just be like that:

//this function will be chosen for both compile time and runtime
constexpr int functiona(){
 // do stuff
}

//when we add non-constexpr function with the same signature, then
constexpr will be chosen on compile-time and
// non-constexpr in runtime e.g

int functiona(){ //runtime only
 // do stuff
}

constexpr int functiona(){ //compile-time only
 // do stuff
}

I think it makes code quite clean as long as both funtions are declared
nearby. For this to work constexpr would have to be probably treated as a
part of signature and some additional rules
for choosing proper function should be probably added.


2017-02-15 23:46 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:

>
>
> On Wednesday, February 15, 2017 at 5:26:47 PM UTC-5, Erich Keane wrote:
>>
>> I believe the outcome of the paper Ville mentions would be more on the
>> line of:
>>
>> if (constexpr()) {}
>> else {}
>>
>> if constexpr(constexpr()) would actually be meaningless, since 'if
>> constexpr' can only execute in a constexpr context, in which constexpr()
>> would always return true.
>>
>
> But that wouldn't work. `constexpr` functions are forbidden from having
> certain constructs: `asm` being the most relevant one here. So you could
> never write this:
>
> constexpr float sin(float i)
> {
>   if (constexpr())
>   {
>     //compile-time implementation.
>   }
>   else
>   {
>     asm { /* Runtime optimized assembly */ }
>   }
> }
>
> A regular `if` statement cannot *eliminate* the code in the not-taken
> branch, so this will still be a compile error. However, an `if constexpr`
> statement already has all of the standards wording needed to expunge such
> code.
>
> As I've said elsewhere, the syntax should just be `if constexpr()`. The
> only reason you would ever even need to ask the question of whether a
> function is currently being executed at compile time is to be able to
> discard non-`constexpr`-legal code. So you would only ever use the results
> as part of an `if constexpr()` condition. So let's just cut out the
> middleman and allow `if constexpr` to ask the question directly.
>
> --
> 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/f07b2509-ab7a-45fb-
> bcc2-af00baccb410%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f07b2509-ab7a-45fb-bcc2-af00baccb410%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/CAOkZZiGW7_BQYEO%2BF%2BcV4CnB7nP%2B6ac9hJUPS%3DOLRxBK-sefZw%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div>Why cannot it just be like that:<br><br></div><d=
iv>//this function will be chosen for both compile time and runtime<br></di=
v>constexpr int functiona(){<br></div>=C2=A0// do stuff<br><div>}<br><br></=
div><div>//when we add non-constexpr function with the same signature, then=
 constexpr will be chosen on compile-time and <br></div><div>// non-constex=
pr in runtime e.g<br><br>int functiona(){ //runtime only<br>=C2=A0// do stu=
ff<br>}<br><br>constexpr int functiona(){ //compile-time only<br>=C2=A0// d=
o stuff<br>}<br><br></div><div>I think it makes code quite clean as long as=
 both funtions are declared nearby. For this to work constexpr would have t=
o be probably treated as a part of signature and some additional rules <br>=
</div><div>for choosing proper function should be probably added.<br></div>=
<div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2017-02-15 23:46 GMT+01:00 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;<=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""=
><br><br>On Wednesday, February 15, 2017 at 5:26:47 PM UTC-5, Erich Keane w=
rote:<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 believe the=
 outcome of the paper Ville mentions would be more on the line of:<br><br>i=
f (constexpr()) {}<br>else {}<br><br>if constexpr(constexpr()) would actual=
ly be meaningless, since &#39;if constexpr&#39; can only execute in a const=
expr context, in which constexpr() would always return true.<br></div></blo=
ckquote></span><div><br>But that wouldn&#39;t work. `constexpr` functions a=
re forbidden from having certain constructs: `asm` being the most relevant =
one here. So you could never write this:<br><br><div style=3D"background-co=
lor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;borde=
r-width:1px" class=3D"m_2237576098371255174prettyprint"><code class=3D"m_22=
37576098371255174prettyprint"><div class=3D"m_2237576098371255174subprettyp=
rint"><span style=3D"color:#008" class=3D"m_2237576098371255174styled-by-pr=
ettify">constexpr</span><span style=3D"color:#000" class=3D"m_2237576098371=
255174styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_223=
7576098371255174styled-by-prettify">float</span><span style=3D"color:#000" =
class=3D"m_2237576098371255174styled-by-prettify"> sin</span><span style=3D=
"color:#660" class=3D"m_2237576098371255174styled-by-prettify">(</span><spa=
n style=3D"color:#008" class=3D"m_2237576098371255174styled-by-prettify">fl=
oat</span><span style=3D"color:#000" class=3D"m_2237576098371255174styled-b=
y-prettify"> i</span><span style=3D"color:#660" class=3D"m_2237576098371255=
174styled-by-prettify">)</span><span style=3D"color:#000" class=3D"m_223757=
6098371255174styled-by-prettify"><br></span><span style=3D"color:#660" clas=
s=3D"m_2237576098371255174styled-by-prettify">{</span><span style=3D"color:=
#000" class=3D"m_2237576098371255174styled-by-prettify"><br>=C2=A0 </span><=
span style=3D"color:#008" class=3D"m_2237576098371255174styled-by-prettify"=
>if</span><span style=3D"color:#000" class=3D"m_2237576098371255174styled-b=
y-prettify"> </span><span style=3D"color:#660" class=3D"m_22375760983712551=
74styled-by-prettify">(</span><span style=3D"color:#008" class=3D"m_2237576=
098371255174styled-by-prettify">constexpr</span><span style=3D"color:#660" =
class=3D"m_2237576098371255174styled-by-prettify">())</span><span style=3D"=
color:#000" class=3D"m_2237576098371255174styled-by-prettify"><br>=C2=A0 </=
span><span style=3D"color:#660" class=3D"m_2237576098371255174styled-by-pre=
ttify">{</span><span style=3D"color:#000" class=3D"m_2237576098371255174sty=
led-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#800" class=
=3D"m_2237576098371255174styled-by-prettify">//compile-time implementation.=
</span><span style=3D"color:#000" class=3D"m_2237576098371255174styled-by-p=
rettify"><br>=C2=A0 </span><span style=3D"color:#660" class=3D"m_2237576098=
371255174styled-by-prettify">}</span><span style=3D"color:#000" class=3D"m_=
2237576098371255174styled-by-prettify"><br>=C2=A0 </span><span style=3D"col=
or:#008" class=3D"m_2237576098371255174styled-by-prettify">else</span><span=
 style=3D"color:#000" class=3D"m_2237576098371255174styled-by-prettify"><br=
>=C2=A0 </span><span style=3D"color:#660" class=3D"m_2237576098371255174sty=
led-by-prettify">{</span><span style=3D"color:#000" class=3D"m_223757609837=
1255174styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#0=
08" class=3D"m_2237576098371255174styled-by-prettify">asm</span><span style=
=3D"color:#000" class=3D"m_2237576098371255174styled-by-prettify"> </span><=
span style=3D"color:#660" class=3D"m_2237576098371255174styled-by-prettify"=
>{</span><span style=3D"color:#000" class=3D"m_2237576098371255174styled-by=
-prettify"> </span><span style=3D"color:#800" class=3D"m_223757609837125517=
4styled-by-prettify">/* Runtime optimized assembly */</span><span style=3D"=
color:#000" class=3D"m_2237576098371255174styled-by-prettify"> </span><span=
 style=3D"color:#660" class=3D"m_2237576098371255174styled-by-prettify">}</=
span><span style=3D"color:#000" class=3D"m_2237576098371255174styled-by-pre=
ttify"><br>=C2=A0 </span><span style=3D"color:#660" class=3D"m_223757609837=
1255174styled-by-prettify">}</span><span style=3D"color:#000" class=3D"m_22=
37576098371255174styled-by-prettify"><br></span><span style=3D"color:#660" =
class=3D"m_2237576098371255174styled-by-prettify">}</span></div></code></di=
v><br>A regular `if` statement cannot <i>eliminate</i> the code in the not-=
taken branch, so this will still be a compile error. However, an `if conste=
xpr` statement already has all of the standards wording needed to expunge s=
uch code.</div><br>As I&#39;ve said elsewhere, the syntax should just be `i=
f constexpr()`. The only reason you would ever even need to ask the questio=
n of whether a function is currently being executed at compile time is to b=
e able to discard non-`constexpr`-legal code. So you would only ever use th=
e results as part of an `if constexpr()` condition. So let&#39;s just cut o=
ut the middleman and allow `if constexpr` to ask the question directly.<br>=
</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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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/f07b2509-ab7a-45fb-bcc2-af00baccb410%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f07b=
2509-ab7a-45fb-<wbr>bcc2-af00baccb410%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOkZZiGW7_BQYEO%2BF%2BcV4CnB7nP%2B6a=
c9hJUPS%3DOLRxBK-sefZw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiGW=
7_BQYEO%2BF%2BcV4CnB7nP%2B6ac9hJUPS%3DOLRxBK-sefZw%40mail.gmail.com</a>.<br=
 />

--f403045f56a41751d60548a2505a--

.

------=_Part_2729_969515269.1487240866689
Content-Type: multipart/alternative;
 boundary="----=_Part_2730_778206228.1487240866689"

------=_Part_2730_778206228.1487240866689
Content-Type: text/plain; charset=UTF-8

On Thursday, February 16, 2017 at 12:20:51 PM UTC+3, Dawid Pilarski wrote:
>
> Why cannot it just be like that:
>
> //this function will be chosen for both compile time and runtime
> constexpr int functiona(){
>  // do stuff
> }
>
> //when we add non-constexpr function with the same signature, then
> constexpr will be chosen on compile-time and
> // non-constexpr in runtime e.g
>
> int functiona(){ //runtime only
>  // do stuff
> }
>
> constexpr int functiona(){ //compile-time only
>  // do stuff
> }
>
> I think it makes code quite clean as long as both funtions are declared
> nearby. For this to work constexpr would have to be probably treated as a
> part of signature and some additional rules
> for choosing proper function should be probably added.
>
Ideally it should be one function and produce the same result in runtime
and compile time (but I think it is impossible in general at least for
floats). This version explicitly declares 2 functions. With if constexpr()
we at least have guaranteed to have only one function prototype/signature.

--
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/464ac791-bb6a-43d5-aea5-dc8f0bc9eff7%40isocpp.org.

------=_Part_2730_778206228.1487240866689
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 16, 2017 at 12:20:51 PM UTC+3, Dawid=
 Pilarski 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"lt=
r"><div><div>Why cannot it just be like that:<br><br></div><div>//this func=
tion will be chosen for both compile time and runtime<br></div>constexpr in=
t functiona(){<br></div>=C2=A0// do stuff<br><div>}<br><br></div><div>//whe=
n we add non-constexpr function with the same signature, then constexpr wil=
l be chosen on compile-time and <br></div><div>// non-constexpr in runtime =
e.g<br><br>int functiona(){ //runtime only<br>=C2=A0// do stuff<br>}<br><br=
>constexpr int functiona(){ //compile-time only<br>=C2=A0// do stuff<br>}<b=
r><br></div><div>I think it makes code quite clean as long as both funtions=
 are declared nearby. For this to work constexpr would have to be probably =
treated as a part of signature and some additional rules <br></div><div>for=
 choosing proper function should be probably added.<br></div><div></div></d=
iv></blockquote><div>Ideally it should be one function and produce the same=
 result in runtime and compile time (but I think it is impossible in genera=
l at least for floats). This version explicitly declares 2 functions. With =
if constexpr() we at least have guaranteed to have only one function protot=
ype/signature.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/464ac791-bb6a-43d5-aea5-dc8f0bc9eff7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/464ac791-bb6a-43d5-aea5-dc8f0bc9eff7=
%40isocpp.org</a>.<br />

------=_Part_2730_778206228.1487240866689--

------=_Part_2729_969515269.1487240866689--

.

--f403045f19ac1fc5380548a372f6
Content-Type: text/plain; charset=UTF-8

I see solution with two functions much cleaner, than having one function
with some obligatory ifs and code nesting.

2017-02-16 11:27 GMT+01:00 Victor Dyachenko <victor.dyachenko@gmail.com>:

> On Thursday, February 16, 2017 at 12:20:51 PM UTC+3, Dawid Pilarski wrote:
>>
>> Why cannot it just be like that:
>>
>> //this function will be chosen for both compile time and runtime
>> constexpr int functiona(){
>>  // do stuff
>> }
>>
>> //when we add non-constexpr function with the same signature, then
>> constexpr will be chosen on compile-time and
>> // non-constexpr in runtime e.g
>>
>> int functiona(){ //runtime only
>>  // do stuff
>> }
>>
>> constexpr int functiona(){ //compile-time only
>>  // do stuff
>> }
>>
>> I think it makes code quite clean as long as both funtions are declared
>> nearby. For this to work constexpr would have to be probably treated as a
>> part of signature and some additional rules
>> for choosing proper function should be probably added.
>>
> Ideally it should be one function and produce the same result in runtime
> and compile time (but I think it is impossible in general at least for
> floats). This version explicitly declares 2 functions. With if constexpr()
> we at least have guaranteed to have only one function prototype/signature.
>
> --
> 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/464ac791-bb6a-43d5-
> aea5-dc8f0bc9eff7%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464ac791-bb6a-43d5-aea5-dc8f0bc9eff7%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/CAOkZZiHFKtna74DC6-JXp2guL2DkPQ4uORv-01ZRbCCz3OooZQ%40mail.gmail.com.

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

<div dir=3D"ltr">I see solution with two functions much cleaner, than havin=
g one function with some obligatory ifs and code nesting.<br></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-02-16 11:27 GMT+01:0=
0 Victor Dyachenko <span dir=3D"ltr">&lt;<a href=3D"mailto:victor.dyachenko=
@gmail.com" target=3D"_blank">victor.dyachenko@gmail.com</a>&gt;</span>:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Thursd=
ay, February 16, 2017 at 12:20:51 PM UTC+3, Dawid Pilarski 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"><div><div>Why cannot it just=
 be like that:<br><br></div><div>//this function will be chosen for both co=
mpile time and runtime<br></div>constexpr int functiona(){<br></div>=C2=A0/=
/ do stuff<br><div>}<br><br></div><div>//when we add non-constexpr function=
 with the same signature, then constexpr will be chosen on compile-time and=
 <br></div><div>// non-constexpr in runtime e.g<br><br>int functiona(){ //r=
untime only<br>=C2=A0// do stuff<br>}<br><br>constexpr int functiona(){ //c=
ompile-time only<br>=C2=A0// do stuff<br>}<br><br></div><div>I think it mak=
es code quite clean as long as both funtions are declared nearby. For this =
to work constexpr would have to be probably treated as a part of signature =
and some additional rules <br></div><div>for choosing proper function shoul=
d be probably added.<br></div><div></div></div></blockquote></span><div>Ide=
ally it should be one function and produce the same result in runtime and c=
ompile time (but I think it is impossible in general at least for floats). =
This version explicitly declares 2 functions. With if constexpr() we at lea=
st have guaranteed to have only one function prototype/signature.<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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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/464ac791-bb6a-43d5-aea5-dc8f0bc9eff7%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/464a=
c791-bb6a-43d5-<wbr>aea5-dc8f0bc9eff7%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOkZZiHFKtna74DC6-JXp2guL2DkPQ4uORv-=
01ZRbCCz3OooZQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiHFKtna74DC=
6-JXp2guL2DkPQ4uORv-01ZRbCCz3OooZQ%40mail.gmail.com</a>.<br />

--f403045f19ac1fc5380548a372f6--

.

------=_Part_11769_1742349093.1487263695065
Content-Type: multipart/alternative;
 boundary="----=_Part_11770_488140036.1487263695065"

------=_Part_11770_488140036.1487263695065
Content-Type: text/plain; charset=UTF-8

You can definitely call non-constexpr functions from a constexpr function,
as long as it isn't on the 'constexpr' path.  SO, you could simply call the
'asm' block (or a try/catch, etc) in a separate function.  See:


constexpr float sin (float i)
{
  if (constexpr())
    return sin_ce_impl(i);
  else
    return sin_asm_impl(i);
}


With proper inlining, that ought to work equivilently to your example.


On Wednesday, February 15, 2017 at 2:46:47 PM UTC-8, Nicol Bolas wrote:
>
>
>
> On Wednesday, February 15, 2017 at 5:26:47 PM UTC-5, Erich Keane wrote:
>>
>> I believe the outcome of the paper Ville mentions would be more on the
>> line of:
>>
>> if (constexpr()) {}
>> else {}
>>
>> if constexpr(constexpr()) would actually be meaningless, since 'if
>> constexpr' can only execute in a constexpr context, in which constexpr()
>> would always return true.
>>
>
> But that wouldn't work. `constexpr` functions are forbidden from having
> certain constructs: `asm` being the most relevant one here. So you could
> never write this:
>
> constexpr float sin(float i)
> {
>   if (constexpr())
>   {
>     //compile-time implementation.
>   }
>   else
>   {
>     asm { /* Runtime optimized assembly */ }
>   }
> }
>
> A regular `if` statement cannot *eliminate* the code in the not-taken
> branch, so this will still be a compile error. However, an `if constexpr`
> statement already has all of the standards wording needed to expunge such
> code.
>
> As I've said elsewhere, the syntax should just be `if constexpr()`. The
> only reason you would ever even need to ask the question of whether a
> function is currently being executed at compile time is to be able to
> discard non-`constexpr`-legal code. So you would only ever use the results
> as part of an `if constexpr()` condition. So let's just cut out the
> middleman and allow `if constexpr` to ask the question directly.
>

--
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/08788c4b-283a-4e74-a551-a33751a36ff1%40isocpp.org.

------=_Part_11770_488140036.1487263695065
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You can definitely call non-constexpr functions from a con=
stexpr function, as long as it isn&#39;t on the &#39;constexpr&#39; path.=
=C2=A0 SO, you could simply call the &#39;asm&#39; block (or a try/catch, e=
tc) in a separate function.=C2=A0 See:<br><br><div style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> sin </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">float</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></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 style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">constexpr</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">())</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> sin_ce_impl</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">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=A0=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">else</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> sin_asm_i=
mpl</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"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br><br></span></div></code></div><br>With prope=
r inlining, that ought to work equivilently to your example.<br><br><br>On =
Wednesday, February 15, 2017 at 2:46:47 PM UTC-8, Nicol Bolas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>On Wednesday=
, February 15, 2017 at 5:26:47 PM UTC-5, Erich Keane wrote:<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">I believe the outcome of the paper=
 Ville mentions would be more on the line of:<br><br>if (constexpr()) {}<br=
>else {}<br><br>if constexpr(constexpr()) would actually be meaningless, si=
nce &#39;if constexpr&#39; can only execute in a constexpr context, in whic=
h constexpr() would always return true.<br></div></blockquote><div><br>But =
that wouldn&#39;t work. `constexpr` functions are forbidden from having cer=
tain constructs: `asm` being the most relevant one here. So you could never=
 write this:<br><br><div style=3D"background-color:rgb(250,250,250);border-=
color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><spa=
n style=3D"color:#008">constexpr</span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">float</span><span style=3D"color:#000"> sin</span=
><span style=3D"color:#660">(</span><span style=3D"color:#008">float</span>=
<span style=3D"color:#000"> i</span><span style=3D"color:#660">)</span><spa=
n style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span =
style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">if</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span=
 style=3D"color:#008">constexpr</span><span style=3D"color:#660">())</span>=
<span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#660">{</=
span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or:#800">//compile-time implementation.</span><span style=3D"color:#000"><b=
r>=C2=A0 </span><span style=3D"color:#660">}</span><span style=3D"color:#00=
0"><br>=C2=A0 </span><span style=3D"color:#008">else</span><span style=3D"c=
olor:#000"><br>=C2=A0 </span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">asm</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#800">/* Runtime opti=
mized assembly */</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">}</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=
=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">}</span></div></code></div><br>A regular `if` statement can=
not <i>eliminate</i> the code in the not-taken branch, so this will still b=
e a compile error. However, an `if constexpr` statement already has all of =
the standards wording needed to expunge such code.</div><br>As I&#39;ve sai=
d elsewhere, the syntax should just be `if constexpr()`. The only reason yo=
u would ever even need to ask the question of whether a function is current=
ly being executed at compile time is to be able to discard non-`constexpr`-=
legal code. So you would only ever use the results as part of an `if conste=
xpr()` condition. So let&#39;s just cut out the middleman and allow `if con=
stexpr` to ask the question directly.<br></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/08788c4b-283a-4e74-a551-a33751a36ff1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/08788c4b-283a-4e74-a551-a33751a36ff1=
%40isocpp.org</a>.<br />

------=_Part_11770_488140036.1487263695065--

------=_Part_11769_1742349093.1487263695065--

.

------=_Part_9359_2063390184.1487276882221
Content-Type: multipart/alternative;
 boundary="----=_Part_9360_591434134.1487276882221"

------=_Part_9360_591434134.1487276882221
Content-Type: text/plain; charset=UTF-8

On Thursday, February 16, 2017 at 11:48:15 AM UTC-5, Erich Keane wrote:
>
> You can definitely call non-constexpr functions from a constexpr function,
> as long as it isn't on the 'constexpr' path.  SO, you could simply call the
> 'asm' block (or a try/catch, etc) in a separate function.  See:
>
>
> constexpr float sin (float i)
> {
>   if (constexpr())
>     return sin_ce_impl(i);
>   else
>     return sin_asm_impl(i);
> }
>
>
>
That specifically requires language in the standard for the rules of
`constexpr` to ignore things not "on the 'constexpr' path". Right now, no
such language exists; if your function is not a template function, and it
has *any* use of constructs that are not `constexpr` legal, then it is
ill-formed.

Template functions are exempt from this, but only so long as it is
theoretically possible for them to be instantiated in such a way that it
would be legal in a `constexpr` function. That is, you can have a global
`constexpr size<T>(const T&t)` function which is `constexpr` so long as
`T::size()` is `constexpr`.

What you're wanting to do is something very much like `if constexpr`, which
for non-template functions causes the not-taken branch to be discarded.
Since we already have language for how discarding statements works, let's *use
that*.

Let's not re-invent the wheel and arbitrarily decide that some kinds of
conditional expressions can cause statement discarding and other kinds
cannot.


> With proper inlining, that ought to work equivilently to your example.
>

--
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/641c8688-d771-463e-9da4-a8692a620fb8%40isocpp.org.

------=_Part_9360_591434134.1487276882221
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 16, 2017 at 11:48:15 AM UTC-5, Erich=
 Keane wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
You can definitely call non-constexpr functions from a constexpr function, =
as long as it isn&#39;t on the &#39;constexpr&#39; path.=C2=A0 SO, you coul=
d simply call the &#39;asm&#39; block (or a try/catch, etc) in a separate f=
unction.=C2=A0 See:<br><br><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><d=
iv><span style=3D"color:#000"><br></span><span style=3D"color:#008">constex=
pr</span><span style=3D"color:#000"> </span><span style=3D"color:#008">floa=
t</span><span style=3D"color:#000"> sin </span><span style=3D"color:#660">(=
</span><span style=3D"color:#008">float</span><span style=3D"color:#000"> i=
</span><span style=3D"color:#660">)</span><span style=3D"color:#000"><br></=
span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=
=A0 </span><span style=3D"color:#008">if</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">(</span><span style=3D"color:#008">conste=
xpr</span><span style=3D"color:#660">())</span><span style=3D"color:#000"><=
br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">return</span><span style=
=3D"color:#000"> sin_ce_impl</span><span style=3D"color:#660">(</span><span=
 style=3D"color:#000">i</span><span style=3D"color:#660">);</span><span sty=
le=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">else</span><=
span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#00=
8">return</span><span style=3D"color:#000"> sin_asm_impl</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">i</span><span style=3D"c=
olor:#660">);</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#660">}</span><span style=3D"color:#000"><br><br></span></div></code></=
div><br></div></blockquote><div><br>That specifically requires language in =
the standard for the rules of `constexpr` to ignore things not &quot;on the=
 &#39;constexpr&#39; path&quot;. Right now, no such language exists; if you=
r function is not a template function, and it has <i>any</i> use of constru=
cts that are not `constexpr` legal, then it is ill-formed.<br><br>Template =
functions are exempt from this, but only so long as it is theoretically pos=
sible for them to be instantiated in such a way that it would be legal in a=
 `constexpr` function. That is, you can have a global `constexpr size&lt;T&=
gt;(const T&amp;t)` function which is `constexpr` so long as `T::size()` is=
 `constexpr`.<br><br>What you&#39;re wanting to do is something very much l=
ike `if constexpr`, which for non-template functions causes the not-taken b=
ranch to be discarded. Since we already have language for how discarding st=
atements works, let&#39;s <i>use that</i>.<br><br>Let&#39;s not re-invent t=
he wheel and arbitrarily decide that some kinds of conditional expressions =
can cause statement discarding and other kinds cannot.<br>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">With proper inlini=
ng, that ought to work equivilently to your example.</div></blockquote></di=
v>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/641c8688-d771-463e-9da4-a8692a620fb8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/641c8688-d771-463e-9da4-a8692a620fb8=
%40isocpp.org</a>.<br />

------=_Part_9360_591434134.1487276882221--

------=_Part_9359_2063390184.1487276882221--

.

On 2017-02-16 15:28, Nicol Bolas wrote:
> On Thursday, February 16, 2017 at 11:48:15 AM UTC-5, Erich Keane wrote:
>> You can definitely call non-constexpr functions from a constexpr function,
>> as long as it isn't on the 'constexpr' path.  SO, you could simply call the
>> 'asm' block (or a try/catch, etc) in a separate function.  See:
>>
>> constexpr float sin (float i)
>> {
>>   if (constexpr())
>>     return sin_ce_impl(i);
>>   else
>>     return sin_asm_impl(i);
>> }
>
> That specifically requires language in the standard for the rules of
> `constexpr` to ignore things not "on the 'constexpr' path". Right now, no
> such language exists; if your function is not a template function, and it
> has *any* use of constructs that are not `constexpr` legal, then it is
> ill-formed.
>
> What you're wanting to do is something very much like `if constexpr`, which
> for non-template functions causes the not-taken branch to be discarded.
> Since we already have language for how discarding statements works, let's *use
> that*.

I tend to agree, and I share your concern. The only "tricky" part I see
is that the compiler must take a different branch of the `if constexpr`
when emitting the run-time version of the function as it takes when
evaluating the function at compile time (i.e. in constexpr context), and
that might be subject to a similar argument.

Of course, that needs to happen *however* we implement the feature...

OTOH, we can already do things like:

  template <int N> constexpr int foo()
  {
    if constexpr (n > 0) ...
    else ...
  }

....so that's not *entirely* unprecedented. Essentially, the presence of
the proposed check (however it winds up being spelled) implicitly makes
the function a template, where the two instantiations are for
compile-time and run-time.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58A6153D.4060609%40gmail.com.

.

------=_Part_45_2078258609.1487288014757
Content-Type: multipart/alternative;
 boundary="----=_Part_46_1363367147.1487288014757"

------=_Part_46_1363367147.1487288014757
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thursday, February 16, 2017 at 12:28:02 PM UTC-8, Nicol Bolas wrote:
>
> On Thursday, February 16, 2017 at 11:48:15 AM UTC-5, Erich Keane wrote:
>>
>> You can definitely call non-constexpr functions from a constexpr=20
>> function, as long as it isn't on the 'constexpr' path.  SO, you could=20
>> simply call the 'asm' block (or a try/catch, etc) in a separate function=
.. =20
>> See:
>>
>>
>> constexpr float sin (float i)
>> {
>>   if (constexpr())
>>     return sin_ce_impl(i);
>>   else
>>     return sin_asm_impl(i);
>> }
>>
>>
>>
> That specifically requires language in the standard for the rules of=20
> `constexpr` to ignore things not "on the 'constexpr' path". Right now, no=
=20
> such language exists; if your function is not a template function, and it=
=20
> has *any* use of constructs that are not `constexpr` legal, then it is=20
> ill-formed.
>

I am missing that part in the standard, mind pointing it out for me?  All I=
=20
see is 7.1.5/3.5:
3.5) its function-body shall be =3D delete, =3D default , or a=20
compound-statement that does not contain
=E2=80=94(3.5.1)an asm-definition,
=E2=80=94(3.5.2)a goto statement,
=E2=80=94(3.5.3)an identifier label (6.1),
=E2=80=94(3.5.4)a try-block, or
=E2=80=94(3.5.5)a definition of a variable of non-literal type or of static=
 or=20
thread storage duration or for which no
initialization is performed.


I DO see paragraph 7 there that says:
A call to a constexpr function produces the same result as a call to an=20
equivalent non-constexpr function in
all respects except that
=E2=80=94(7.1)a call to a constexpr function can appear in a constant expre=
ssion=20
(5.20) and ...

Though, that is the only place that is asserted.  I wonder if the change in=
=20
C++14 to change 3.5 from "only contain" to "does not contain" missed this=
=20
situation...

My preference would be to have constexpr execution ONLY fail in the case=20
where said branch is not executed (independent of whether or not=20
constexpr() =3D=3D true).  This would properly reflect the current behavior=
 of=20
clang/gcc, and allow the current constexpr tricks that people are using=20
anyway (which uses exceptions in constexpr to make it fail!).
=20


> Template functions are exempt from this, but only so long as it is=20
> theoretically possible for them to be instantiated in such a way that it=
=20
> would be legal in a `constexpr` function. That is, you can have a global=
=20
> `constexpr size<T>(const T&t)` function which is `constexpr` so long as=
=20
> `T::size()` is `constexpr`.
>
> What you're wanting to do is something very much like `if constexpr`,=20
> which for non-template functions causes the not-taken branch to be=20
> discarded. Since we already have language for how discarding statements=
=20
> works, let's *use that*.
>
> Let's not re-invent the wheel and arbitrarily decide that some kinds of=
=20
> conditional expressions can cause statement discarding and other kinds=20
> cannot.
> =20
>
>> With proper inlining, that ought to work equivilently to your example.
>>
>

--=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/effe23d1-05d0-42b3-9735-8e5461457167%40isocpp.or=
g.

------=_Part_46_1363367147.1487288014757
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, February 16, 2017 at 12:28:02 PM UTC-=
8, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Thursday, February 16, 2017 at 11:48:15 AM UTC-5, Erich Keane w=
rote:<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">You can defin=
itely call non-constexpr functions from a constexpr function, as long as it=
 isn&#39;t on the &#39;constexpr&#39; path.=C2=A0 SO, you could simply call=
 the &#39;asm&#39; block (or a try/catch, etc) in a separate function.=C2=
=A0 See:<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span st=
yle=3D"color:#000"><br></span><span style=3D"color:#008">constexpr</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#008">float</span><sp=
an style=3D"color:#000"> sin </span><span style=3D"color:#660">(</span><spa=
n style=3D"color:#008">float</span><span style=3D"color:#000"> i</span><spa=
n style=3D"color:#660">)</span><span style=3D"color:#000"><br></span><span =
style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </span><=
span style=3D"color:#008">if</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#660">(</span><span style=3D"color:#008">constexpr</span><s=
pan style=3D"color:#660">())</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color:#008">return</span><span style=3D"color:=
#000"> sin_ce_impl</span><span style=3D"color:#660">(</span><span style=3D"=
color:#000">i</span><span style=3D"color:#660">);</span><span style=3D"colo=
r:#000"><br>=C2=A0 </span><span style=3D"color:#008">else</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">return<=
/span><span style=3D"color:#000"> sin_asm_impl</span><span style=3D"color:#=
660">(</span><span style=3D"color:#000">i</span><span style=3D"color:#660">=
);</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}=
</span><span style=3D"color:#000"><br><br></span></div></code></div><br></d=
iv></blockquote><div><br>That specifically requires language in the standar=
d for the rules of `constexpr` to ignore things not &quot;on the &#39;const=
expr&#39; path&quot;. Right now, no such language exists; if your function =
is not a template function, and it has <i>any</i> use of constructs that ar=
e not `constexpr` legal, then it is ill-formed.<br></div></div></blockquote=
><div><br>I am missing that part in the standard, mind pointing it out for =
me?=C2=A0 All I see is 7.1.5/3.5:<br>3.5) its function-body shall be =3D de=
lete, =3D default , or a compound-statement that does not contain<br>=E2=80=
=94(3.5.1)an asm-definition,<br>=E2=80=94(3.5.2)a goto statement,<br>=E2=80=
=94(3.5.3)an identifier label (6.1),<br>=E2=80=94(3.5.4)a try-block, or<br>=
=E2=80=94(3.5.5)a definition of a variable of non-literal type or of static=
 or thread storage duration or for which no<br>initialization is performed.=
<br><br><br>I DO see paragraph 7 there that says:<br>A call to a constexpr =
function produces the same result as a call to an equivalent non-constexpr =
function in<br>all respects except that<br>=E2=80=94(7.1)a call to a conste=
xpr function can appear in a constant expression (5.20) and ...<br><br>Thou=
gh, that is the only place that is asserted.=C2=A0 I wonder if the change i=
n C++14 to change 3.5 from &quot;only contain&quot; to &quot;does not conta=
in&quot; missed this situation...<br><br>My preference would be to have con=
stexpr execution ONLY fail in the case where said branch is not executed (i=
ndependent of whether or not constexpr() =3D=3D true).=C2=A0 This would pro=
perly reflect the current behavior of clang/gcc, and allow the current cons=
texpr tricks that people are using anyway (which uses exceptions in constex=
pr to make it fail!).<br>=C2=A0<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><br>Template functions are exempt from=
 this, but only so long as it is theoretically possible for them to be inst=
antiated in such a way that it would be legal in a `constexpr` function. Th=
at is, you can have a global `constexpr size&lt;T&gt;(const T&amp;t)` funct=
ion which is `constexpr` so long as `T::size()` is `constexpr`.<br><br>What=
 you&#39;re wanting to do is something very much like `if constexpr`, which=
 for non-template functions causes the not-taken branch to be discarded. Si=
nce we already have language for how discarding statements works, let&#39;s=
 <i>use that</i>.<br><br>Let&#39;s not re-invent the wheel and arbitrarily =
decide that some kinds of conditional expressions can cause statement disca=
rding and other kinds cannot.<br>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">With proper inlining, that ought to work equivil=
ently to your example.</div></blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/effe23d1-05d0-42b3-9735-8e5461457167%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/effe23d1-05d0-42b3-9735-8e5461457167=
%40isocpp.org</a>.<br />

------=_Part_46_1363367147.1487288014757--

------=_Part_45_2078258609.1487288014757--

.