------=_Part_13132_2031270130.1531181051089
Content-Type: multipart/alternative;
 boundary="----=_Part_13133_540229585.1531181051089"

------=_Part_13133_540229585.1531181051089
Content-Type: text/plain; charset="UTF-8"

Hello everyone

Have the authors of p10731r.html considered if this suggestion:

constexpr(true) int sqr(int n) {
  return n*n;
}

is preferable and more consistent or flexible than this which they
currently propose:

constexpr! int sqr(int n) {
  return n*n;
}

And would it offer the following possibility and would it be useful?:

constexpr(some_condition()) int sqr(int n) { // constexpr this function on
certain conditions.
  return n*n;
}

Also many compilers support forceinline functionality etc. Perhaps this
should be standardized too now?
Therefore I think the authors might want to propose this too:

inline(false) int sqr(int n) { // force inline. Or inline! if the committee
thinks best.
  return n*n;
}

Which might similarly allow this?:
inline(some_other_condiition()) int sqr(int n) { // force inline. Or
inline! if the committee thinks best.
  return n*n;
}

where some_other_condition might test for a certain platform or compile
where forcing inline or not might be desirable despite what the compiler
thinks.

It seems to me using ! is a little unusual syntax and be less consistent
and flexible than what I'm proposing but I admit ! is shorter.

I see such macros regarding forceinline in various code bases such as
libcxx's __config file. So perhaps forceinline's time has come too.

What do the authors of p1073r1 and others think?

Thanks
Show trimmed content
Click here to Reply

--
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/f377a21c-926e-4cd8-9c25-5c36b7a7a62c%40isocpp.org.

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

<div dir=3D"ltr"><div style=3D"max-height: 10000px;"><div dir=3D"ltr"><div>=
Hello everyone</div><div><br>Have the authors of=C2=A0p10731r.html consider=
ed if this suggestion:</div><div><br></div><p>constexpr(true) int sqr(int n=
) {<br>=C2=A0 return n*n;<br>}</p><div><br></div><div>is preferable and mor=
e consistent or flexible than this which=C2=A0they currently propose:</div>=
<div><br></div><div>constexpr! int sqr(int n) {<br>=C2=A0 return n*n;<br>}<=
/div><div><br></div><div>And would=C2=A0it offer=C2=A0the following=C2=A0po=
ssibility and would it be useful?:</div><div><br></div><div>constexpr(some_=
condition()) int sqr(int n) { //=C2=A0constexpr this function=C2=A0on certa=
in=C2=A0conditions.<br>=C2=A0 return n*n;<br>}</div><div><br>Also=C2=A0many=
 compilers support=C2=A0forceinline functionality etc. Perhaps this should =
be standardized too now?</div><div>Therefore I think the authors might want=
 to=C2=A0propose this too:</div><div><br></div><div>inline(false) int sqr(i=
nt n) { // force inline. Or inline! if the committee thinks best.<br>=C2=A0=
 return n*n;<br>}</div><div><br></div><div>Which might similarly allow this=
?:</div><div>inline(some_other_condiition()<wbr>) int sqr(int n) { // force=
 inline. Or inline! if the committee thinks best.<br>=C2=A0 return n*n;<br>=
}</div><div><br></div><div>where some_other_condition might=C2=A0test for a=
 certain platform or compile where forcing inline or not might be desirable=
 despite what the compiler thinks.</div><div><br></div><div>It seems to me =
using ! is a little unusual syntax=C2=A0and be less consistent and flexible=
 than what I&#39;m proposing but=C2=A0I admit ! is shorter.</div><div><div>=
<br></div><div>I see such macros regarding forceinline in various code base=
s such as libcxx&#39;s __config file. So perhaps forceinline&#39;s time has=
 come too.</div></div><div><br></div><div>What do the authors of=C2=A0p1073=
r1 and others think?</div><div><br></div><div>Thanks<br></div></div></div><=
a class=3D"gwt-Anchor" aria-hidden=3D"true" style=3D"display: none;">Show t=
rimmed content</a> <div class=3D"F0XO1GC-nb-P" style=3D"display: none;"><di=
v></div></div><div></div><div></div><div style=3D"display: none;"></div><di=
v style=3D"display: none;"></div><div><div class=3D"F0XO1GC-ed-a"></div></d=
iv><div class=3D"F0XO1GC-nb-b"><div class=3D"F0XO1GC-nb-a F0XO1GC-nb-cb"><d=
iv><div style=3D"display: inline-block;"><div style=3D"display: none;"></di=
v></div> <div class=3D"F0XO1GC-md-a"><div class=3D"F0XO1GC-md-b" id=3D"q_re=
ply">Click here to <span class=3D"F0XO1GC-md-c">Reply</span></div></div></d=
iv></div></div></div>

<p></p>

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

------=_Part_13133_540229585.1531181051089--

------=_Part_13132_2031270130.1531181051089--

.

--000000000000a32dcb05709fc596
Content-Type: text/plain; charset="UTF-8"

On Tue, 10 Jul 2018 at 02:04, <gmisocpp@gmail.com> wrote:

> Hello everyone
>
> Have the authors of p10731r.html considered if this suggestion:
>
> constexpr(true) int sqr(int n) {
>   return n*n;
> }
>
> is preferable and more consistent or flexible than this which they
> currently propose:
>
> constexpr! int sqr(int n) {
>   return n*n;
> }
>
> And would it offer the following possibility and would it be useful?:
>
> constexpr(some_condition()) int sqr(int n) { // constexpr this function on
> certain conditions.
>   return n*n;
> }
>
> Also many compilers support forceinline functionality etc. Perhaps this
> should be standardized too now?
> Therefore I think the authors might want to propose this too:
>
> inline(false) int sqr(int n) { // force inline. Or inline! if the
> committee thinks best.
>   return n*n;
> }
>
> Which might similarly allow this?:
> inline(some_other_condiition()) int sqr(int n) { // force inline. Or
> inline! if the committee thinks best.
>   return n*n;
> }
>
> where some_other_condition might test for a certain platform or compile
> where forcing inline or not might be desirable despite what the compiler
> thinks.
>
> It seems to me using ! is a little unusual syntax and be less consistent
> and flexible than what I'm proposing but I admit ! is shorter.
>
> I see such macros regarding forceinline in various code bases such as
> libcxx's __config file. So perhaps forceinline's time has come too.
>
> What do the authors of p1073r1 and others think?
>

What one of the others thinks:

a) The exclamation mark on the end is revolting, adding nothing to the
syntax.

b) Do you have a compelling, motivating use case in mind? By this I mean a
real one, not just "we ought to have it because it seems consistent".

I ask for b) because I am strongly of the view that code should express
intent, which the compiler then turns into action. What is the "intent" of
writing:

constexpr(some_test()) int sqr(int n);

?

What could some_test() possibly be testing? Why would it matter? The
implementation of sqr is either a constexpr expression or it's not. If it
is, its constexpr-ness can be undone by the context of its use (because it
takes an argument). What's wrong with that?




>
> Thanks
> Show trimmed content
> Click here to Reply
>
> --
> 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/f377a21c-926e-4cd8-9c25-5c36b7a7a62c%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f377a21c-926e-4cd8-9c25-5c36b7a7a62c%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/CALvx3hZ8bNfWMYvzty1Dzh6OXs029k5t-nr1m1nP9uCgisA21Q%40mail.gmail.com.

--000000000000a32dcb05709fc596
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=
, 10 Jul 2018 at 02:04, &lt;<a href=3D"mailto:gmisocpp@gmail.com">gmisocpp@=
gmail.com</a>&gt; 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"ltr"><div style=3D"max-height:10000px"><div dir=3D"ltr"><div>Hello ever=
yone</div><div><br>Have the authors of=C2=A0p10731r.html considered if this=
 suggestion:</div><div><br></div><p>constexpr(true) int sqr(int n) {<br>=C2=
=A0 return n*n;<br>}</p><div><br></div><div>is preferable and more consiste=
nt or flexible than this which=C2=A0they currently propose:</div><div><br><=
/div><div>constexpr! int sqr(int n) {<br>=C2=A0 return n*n;<br>}</div><div>=
<br></div><div>And would=C2=A0it offer=C2=A0the following=C2=A0possibility =
and would it be useful?:</div><div><br></div><div>constexpr(some_condition(=
)) int sqr(int n) { //=C2=A0constexpr this function=C2=A0on certain=C2=A0co=
nditions.<br>=C2=A0 return n*n;<br>}</div><div><br>Also=C2=A0many compilers=
 support=C2=A0forceinline functionality etc. Perhaps this should be standar=
dized too now?</div><div>Therefore I think the authors might want to=C2=A0p=
ropose this too:</div><div><br></div><div>inline(false) int sqr(int n) { //=
 force inline. Or inline! if the committee thinks best.<br>=C2=A0 return n*=
n;<br>}</div><div><br></div><div>Which might similarly allow this?:</div><d=
iv>inline(some_other_condiition()) int sqr(int n) { // force inline. Or inl=
ine! if the committee thinks best.<br>=C2=A0 return n*n;<br>}</div><div><br=
></div><div>where some_other_condition might=C2=A0test for a certain platfo=
rm or compile where forcing inline or not might be desirable despite what t=
he compiler thinks.</div><div><br></div><div>It seems to me using ! is a li=
ttle unusual syntax=C2=A0and be less consistent and flexible than what I&#3=
9;m proposing but=C2=A0I admit ! is shorter.</div><div><div><br></div><div>=
I see such macros regarding forceinline in various code bases such as libcx=
x&#39;s __config file. So perhaps forceinline&#39;s time has come too.</div=
></div><div><br></div><div>What do the authors of=C2=A0p1073r1 and others t=
hink?</div></div></div></div></blockquote><div><br></div><div>What one of t=
he others thinks:</div><div><br></div><div>a) The exclamation mark on the e=
nd is revolting, adding nothing to the syntax.</div><div><br></div><div>b) =
Do you have a compelling, motivating use case in mind? By this I mean a rea=
l one, not just &quot;we ought to have it because it seems consistent&quot;=
..</div><div><br></div><div>I ask for b) because I am strongly of the view t=
hat code should express intent, which the compiler then turns into action. =
What is the &quot;intent&quot; of writing:</div><div><br></div><div><font f=
ace=3D"monospace, monospace">constexpr(some_test()) int sqr(int n);</font>=
=C2=A0</div><div><br></div><div>?</div><div><br></div><div>What could some_=
test() possibly be testing? Why would it matter? The implementation of sqr =
is either a constexpr expression or it&#39;s not. If it is, its constexpr-n=
ess can be undone by the context of its use (because it takes an argument).=
 What&#39;s wrong with that?</div><div><br></div><div>=C2=A0</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"max-=
height:10000px"><div dir=3D"ltr"><div><br></div><div>Thanks<br></div></div>=
</div><a class=3D"m_3103454968196976081gwt-Anchor" style=3D"display:none">S=
how trimmed content</a> <div class=3D"m_3103454968196976081F0XO1GC-nb-P" st=
yle=3D"display:none"><div></div></div><div></div><div></div><div style=3D"d=
isplay:none"></div><div style=3D"display:none"></div><div><div class=3D"m_3=
103454968196976081F0XO1GC-ed-a"></div></div><div class=3D"m_310345496819697=
6081F0XO1GC-nb-b"><div class=3D"m_3103454968196976081F0XO1GC-nb-a m_3103454=
968196976081F0XO1GC-nb-cb"><div><div style=3D"display:inline-block"><div st=
yle=3D"display:none"></div></div> <div class=3D"m_3103454968196976081F0XO1G=
C-md-a"><div class=3D"m_3103454968196976081F0XO1GC-md-b" id=3D"m_3103454968=
196976081q_reply">Click here to <span class=3D"m_3103454968196976081F0XO1GC=
-md-c">Reply</span></div></div></div></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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/f377a21c-926e-4cd8-9c25-5c36b7a7a62c%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f377a21c-926e-=
4cd8-9c25-5c36b7a7a62c%40isocpp.org</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&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/CALvx3hZ8bNfWMYvzty1Dzh6OXs029k5t-nr1=
m1nP9uCgisA21Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ8bNfWMYvz=
ty1Dzh6OXs029k5t-nr1m1nP9uCgisA21Q%40mail.gmail.com</a>.<br />

--000000000000a32dcb05709fc596--

.

------=_Part_80998_32369715.1531223674173
Content-Type: multipart/alternative;
 boundary="----=_Part_80999_500634995.1531223674173"

------=_Part_80999_500634995.1531223674173
Content-Type: text/plain; charset="UTF-8"



On Tuesday, July 10, 2018 at 7:06:43 PM UTC+12, Richard Hodges wrote:
>
>
>
> On Tue, 10 Jul 2018 at 02:04, <gmis...@gmail.com <javascript:>> wrote:
>
>> Hello everyone
>>
>> Have the authors of p10731r.html considered if this suggestion:
>>
>> constexpr(true) int sqr(int n) {
>>   return n*n;
>> }
>>
>> is preferable and more consistent or flexible than this which they
>> currently propose:
>>
>> constexpr! int sqr(int n) {
>>   return n*n;
>> }
>>
>> And would it offer the following possibility and would it be useful?:
>>
>> constexpr(some_condition()) int sqr(int n) { // constexpr this
>> function on certain conditions.
>>   return n*n;
>> }
>>
>> Also many compilers support forceinline functionality etc. Perhaps this
>> should be standardized too now?
>> Therefore I think the authors might want to propose this too:
>>
>> inline(false) int sqr(int n) { // force inline. Or inline! if the
>> committee thinks best.
>>   return n*n;
>> }
>>
>> Which might similarly allow this?:
>> inline(some_other_condiition()) int sqr(int n) { // force inline. Or
>> inline! if the committee thinks best.
>>   return n*n;
>> }
>>
>> where some_other_condition might test for a certain platform or compile
>> where forcing inline or not might be desirable despite what the compiler
>> thinks.
>>
>> It seems to me using ! is a little unusual syntax and be less consistent
>> and flexible than what I'm proposing but I admit ! is shorter.
>>
>> I see such macros regarding forceinline in various code bases such as
>> libcxx's __config file. So perhaps forceinline's time has come too.
>>
>> What do the authors of p1073r1 and others think?
>>
>
> What one of the others thinks:
>
> a) The exclamation mark on the end is revolting, adding nothing to the
> syntax.
>
> b) Do you have a compelling, motivating use case in mind? By this I mean a
> real one, not just "we ought to have it because it seems consistent".
>
> I ask for b) because I am strongly of the view that code should express
> intent, which the compiler then turns into action. What is the "intent" of
> writing:
>
> constexpr(some_test()) int sqr(int n);
>
> ?
>
> What could some_test() possibly be testing? Why would it matter? The
> implementation of sqr is either a constexpr expression or it's not. If it
> is, its constexpr-ness can be undone by the context of its use (because it
> takes an argument). What's wrong with that?
>
>
>
The main motivation for my post was I wasn't hot for the ! syntax in
constexpr!. constexpr(true) seems more c++-ish to me.
I can't myself see any reason to want to conditionally constexpr some
function but the non ! syntax doesn't shut any doors if people later did
find a use case.
I wouldn't be desperately unhappy with constexpr! though.

But I'd like to see inline get the same treatment. So we get __forceinline
standardized and it seems it should be consistent with the constexpr syntax,
There I can imagine inline(some_test()) int sqr(int n); might be more
useful, but I'm not sure.
some_test() might return a different value based on some compilers ability
to inline in a desirable way or not.
But even there in reality I imagine people will #if different functions
anyway if that was the case.

__forceline being standardized as inline(true) or inline! is the main thing.
And if there was a use for inline(some_condition()) then it seems
constexpr(true) would be the better syntax to match it even if no real
expression is supported.

--
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/67f9b892-ea8d-43ab-aa42-9e225bcbbbac%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, July 10, 2018 at 7:06:43 PM UTC+12, Ri=
chard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 10 Jul 2018 at 02:04, &lt=
;<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"Nb0GdQwDBgAJ">gmi=
s...@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div di=
r=3D"ltr"><div style=3D"max-height: 10000px;"><div dir=3D"ltr"><div>Hello e=
veryone</div><div><br>Have the authors of=C2=A0p10731r.html considered if t=
his suggestion:</div><div><br></div><p>constexpr(true) int sqr(int n) {<br>=
=C2=A0 return n*n;<br>}</p><div><br></div><div>is preferable and more consi=
stent or flexible than this which=C2=A0they currently propose:</div><div><b=
r></div><div>constexpr! int sqr(int n) {<br>=C2=A0 return n*n;<br>}</div><d=
iv><br></div><div>And would=C2=A0it offer=C2=A0the following=C2=A0possibili=
ty and would it be useful?:</div><div><br></div><div>constexpr(some_conditi=
on()) int sqr(int n) { //=C2=A0constexpr this function=C2=A0on certain=C2=
=A0conditions.<br>=C2=A0 return n*n;<br>}</div><div><br>Also=C2=A0many comp=
ilers support=C2=A0forceinline functionality etc. Perhaps this should be st=
andardized too now?</div><div>Therefore I think the authors might want to=
=C2=A0propose this too:</div><div><br></div><div>inline(false) int sqr(int =
n) { // force inline. Or inline! if the committee thinks best.<br>=C2=A0 re=
turn n*n;<br>}</div><div><br></div><div>Which might similarly allow this?:<=
/div><div>inline(some_other_condiition()<wbr>) int sqr(int n) { // force in=
line. Or inline! if the committee thinks best.<br>=C2=A0 return n*n;<br>}</=
div><div><br></div><div>where some_other_condition might=C2=A0test for a ce=
rtain platform or compile where forcing inline or not might be desirable de=
spite what the compiler thinks.</div><div><br></div><div>It seems to me usi=
ng ! is a little unusual syntax=C2=A0and be less consistent and flexible th=
an what I&#39;m proposing but=C2=A0I admit ! is shorter.</div><div><div><br=
></div><div>I see such macros regarding forceinline in various code bases s=
uch as libcxx&#39;s __config file. So perhaps forceinline&#39;s time has co=
me too.</div></div><div><br></div><div>What do the authors of=C2=A0p1073r1 =
and others think?</div></div></div></div></blockquote><div><br></div><div>W=
hat one of the others thinks:</div><div><br></div><div>a) The exclamation m=
ark on the end is revolting, adding nothing to the syntax.</div><div><br></=
div><div>b) Do you have a compelling, motivating use case in mind? By this =
I mean a real one, not just &quot;we ought to have it because it seems cons=
istent&quot;.</div><div><br></div><div>I ask for b) because I am strongly o=
f the view that code should express intent, which the compiler then turns i=
nto action. What is the &quot;intent&quot; of writing:</div><div><br></div>=
<div><font face=3D"monospace, monospace">constexpr(some_test()) int sqr(int=
 n);</font>=C2=A0</div><div><br></div><div>?</div><div><br></div><div>What =
could some_test() possibly be testing? Why would it matter? The implementat=
ion of sqr is either a constexpr expression or it&#39;s not. If it is, its =
constexpr-ness can be undone by the context of its use (because it takes an=
 argument). What&#39;s wrong with that?</div><div><br></div><div><br></div>=
</div></div></blockquote><div><br></div><div><div>The main motivation=C2=A0=
for my post was=C2=A0I=C2=A0wasn&#39;t hot for=C2=A0the !=C2=A0syntax=C2=A0=
in constexpr!.=C2=A0constexpr(true) seems more c++-ish to me.</div><div>I c=
an&#39;t myself see any reason to want to conditionally constexpr some func=
tion but the non ! syntax doesn&#39;t shut any doors=C2=A0if=C2=A0people la=
ter did find a use case.</div><div>I wouldn&#39;t be desperately unhappy wi=
th constexpr! though.</div></div><div><br></div><div>But I&#39;d like to se=
e inline get the same treatment. So we get=C2=A0__forceinline standardized =
and it seems it should be consistent with the constexpr syntax,</div><div>T=
here I can imagine <font face=3D"monospace, monospace">inline(some_test()) =
int sqr(int n);</font>=C2=A0might be more useful, but I&#39;m not sure.</di=
v><div>some_test() might return a different value based=C2=A0on some compil=
ers=C2=A0ability to inline in a desirable way or not.</div><div>But even th=
ere in reality I imagine people will #if different functions anyway if that=
 was the case.</div><div><br></div><div>__forceline being standardized as i=
nline(true) or inline! is the main thing.</div><div>And=C2=A0if there was a=
 use for inline(some_condition()) then it seems constexpr(true) would be th=
e better syntax to match it even if no real expression is supported.</div><=
div><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/67f9b892-ea8d-43ab-aa42-9e225bcbbbac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/67f9b892-ea8d-43ab-aa42-9e225bcbbbac=
%40isocpp.org</a>.<br />

------=_Part_80999_500634995.1531223674173--

------=_Part_80998_32369715.1531223674173--

.

--0000000000000fd6fc0570a3deec
Content-Type: text/plain; charset="UTF-8"

I don't like this syntax because it is too similar to the noexcept operator
and explicit bool, while being too dissimilar to the effects of those two.

If I read constexpr(true) I would assume that the function is simply
constexpr, not some more strict version of constexpr. Similarly, I'd expect
to write constexpr(f()) so that depending on f, mit function is constexpr
or not. But this is not what is happening, and what I expect to happen is
already possible.

I also don't see the motivation of inline(true) for the same reasons.
Additionally, forced inline is rarely needed and I don't think we should
standardize it, because it would require novel syntax for no real benefit.
Yes, it is useful, but only rarely.

But that's just my opinion.

On Tue, Jul 10, 2018, 1:54 PM <gmisocpp@gmail.com> wrote:

>
>
> On Tuesday, July 10, 2018 at 7:06:43 PM UTC+12, Richard Hodges wrote:
>>
>>
>>
>> On Tue, 10 Jul 2018 at 02:04, <gmis...@gmail.com> wrote:
>>
>>> Hello everyone
>>>
>>> Have the authors of p10731r.html considered if this suggestion:
>>>
>>> constexpr(true) int sqr(int n) {
>>>   return n*n;
>>> }
>>>
>>> is preferable and more consistent or flexible than this which they
>>> currently propose:
>>>
>>> constexpr! int sqr(int n) {
>>>   return n*n;
>>> }
>>>
>>> And would it offer the following possibility and would it be useful?:
>>>
>>> constexpr(some_condition()) int sqr(int n) { // constexpr this
>>> function on certain conditions.
>>>   return n*n;
>>> }
>>>
>>> Also many compilers support forceinline functionality etc. Perhaps this
>>> should be standardized too now?
>>> Therefore I think the authors might want to propose this too:
>>>
>>> inline(false) int sqr(int n) { // force inline. Or inline! if the
>>> committee thinks best.
>>>   return n*n;
>>> }
>>>
>>> Which might similarly allow this?:
>>> inline(some_other_condiition()) int sqr(int n) { // force inline. Or
>>> inline! if the committee thinks best.
>>>   return n*n;
>>> }
>>>
>>> where some_other_condition might test for a certain platform or compile
>>> where forcing inline or not might be desirable despite what the compiler
>>> thinks.
>>>
>>> It seems to me using ! is a little unusual syntax and be less consistent
>>> and flexible than what I'm proposing but I admit ! is shorter.
>>>
>>> I see such macros regarding forceinline in various code bases such as
>>> libcxx's __config file. So perhaps forceinline's time has come too.
>>>
>>> What do the authors of p1073r1 and others think?
>>>
>>
>> What one of the others thinks:
>>
>> a) The exclamation mark on the end is revolting, adding nothing to the
>> syntax.
>>
>> b) Do you have a compelling, motivating use case in mind? By this I mean
>> a real one, not just "we ought to have it because it seems consistent".
>>
>> I ask for b) because I am strongly of the view that code should express
>> intent, which the compiler then turns into action. What is the "intent" of
>> writing:
>>
>> constexpr(some_test()) int sqr(int n);
>>
>> ?
>>
>> What could some_test() possibly be testing? Why would it matter? The
>> implementation of sqr is either a constexpr expression or it's not. If it
>> is, its constexpr-ness can be undone by the context of its use (because it
>> takes an argument). What's wrong with that?
>>
>>
>>
> The main motivation for my post was I wasn't hot for the ! syntax in
> constexpr!. constexpr(true) seems more c++-ish to me.
> I can't myself see any reason to want to conditionally constexpr some
> function but the non ! syntax doesn't shut any doors if people later did
> find a use case.
> I wouldn't be desperately unhappy with constexpr! though.
>
> But I'd like to see inline get the same treatment. So we get __forceinline
> standardized and it seems it should be consistent with the constexpr syntax,
> There I can imagine inline(some_test()) int sqr(int n); might be more
> useful, but I'm not sure.
> some_test() might return a different value based on some compilers ability
> to inline in a desirable way or not.
> But even there in reality I imagine people will #if different functions
> anyway if that was the case.
>
> __forceline being standardized as inline(true) or inline! is the main
> thing.
> And if there was a use for inline(some_condition()) then it seems
> constexpr(true) would be the better syntax to match it even if no real
> expression is supported.
>
> --
> 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/67f9b892-ea8d-43ab-aa42-9e225bcbbbac%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/67f9b892-ea8d-43ab-aa42-9e225bcbbbac%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/CALmDwq2fJ2_tUJa13BWkOACnHqDqJM2q8Bfct2TqCyvsKnDLRg%40mail.gmail.com.

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

<div dir=3D"auto">I don&#39;t like this syntax because it is too similar to=
 the noexcept operator and explicit bool, while being too dissimilar to the=
 effects of those two.<div dir=3D"auto"><br></div><div dir=3D"auto">If I re=
ad constexpr(true) I would assume that the function is simply constexpr, no=
t some more strict version of constexpr. Similarly, I&#39;d expect to write=
 constexpr(f()) so that depending on f, mit function is constexpr or not. B=
ut this is not what is happening, and what I expect to happen is already po=
ssible.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I also don&#39;t=
 see the motivation of inline(true) for the same reasons. Additionally, for=
ced inline is rarely needed and I don&#39;t think we should standardize it,=
 because it would require novel syntax for no real benefit. Yes, it is usef=
ul, but only rarely.</div><div dir=3D"auto"><br></div><div dir=3D"auto">But=
 that&#39;s just my opinion.</div></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr">On Tue, Jul 10, 2018, 1:54 PM  &lt;<a href=3D"mailto:gmisocpp@=
gmail.com">gmisocpp@gmail.com</a>&gt; 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"ltr"><br><br>On Tuesday, July 10, 2018 at 7:06:43 PM =
UTC+12, Richard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);b=
order-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><br><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 10 Jul 2018 at 02:04, &lt;<=
a rel=3D"nofollow noreferrer">gmis...@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-le=
ft:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left=
-style:solid"><div dir=3D"ltr"><div style=3D"max-height:10000px"><div dir=
=3D"ltr"><div>Hello everyone</div><div><br>Have the authors of=C2=A0p10731r=
..html considered if this suggestion:</div><div><br></div><p>constexpr(true)=
 int sqr(int n) {<br>=C2=A0 return n*n;<br>}</p><div><br></div><div>is pref=
erable and more consistent or flexible than this which=C2=A0they currently =
propose:</div><div><br></div><div>constexpr! int sqr(int n) {<br>=C2=A0 ret=
urn n*n;<br>}</div><div><br></div><div>And would=C2=A0it offer=C2=A0the fol=
lowing=C2=A0possibility and would it be useful?:</div><div><br></div><div>c=
onstexpr(some_condition()) int sqr(int n) { //=C2=A0constexpr this function=
=C2=A0on certain=C2=A0conditions.<br>=C2=A0 return n*n;<br>}</div><div><br>=
Also=C2=A0many compilers support=C2=A0forceinline functionality etc. Perhap=
s this should be standardized too now?</div><div>Therefore I think the auth=
ors might want to=C2=A0propose this too:</div><div><br></div><div>inline(fa=
lse) int sqr(int n) { // force inline. Or inline! if the committee thinks b=
est.<br>=C2=A0 return n*n;<br>}</div><div><br></div><div>Which might simila=
rly allow this?:</div><div>inline(some_other_condiition()) int sqr(int n) {=
 // force inline. Or inline! if the committee thinks best.<br>=C2=A0 return=
 n*n;<br>}</div><div><br></div><div>where some_other_condition might=C2=A0t=
est for a certain platform or compile where forcing inline or not might be =
desirable despite what the compiler thinks.</div><div><br></div><div>It see=
ms to me using ! is a little unusual syntax=C2=A0and be less consistent and=
 flexible than what I&#39;m proposing but=C2=A0I admit ! is shorter.</div><=
div><div><br></div><div>I see such macros regarding forceinline in various =
code bases such as libcxx&#39;s __config file. So perhaps forceinline&#39;s=
 time has come too.</div></div><div><br></div><div>What do the authors of=
=C2=A0p1073r1 and others think?</div></div></div></div></blockquote><div><b=
r></div><div>What one of the others thinks:</div><div><br></div><div>a) The=
 exclamation mark on the end is revolting, adding nothing to the syntax.</d=
iv><div><br></div><div>b) Do you have a compelling, motivating use case in =
mind? By this I mean a real one, not just &quot;we ought to have it because=
 it seems consistent&quot;.</div><div><br></div><div>I ask for b) because I=
 am strongly of the view that code should express intent, which the compile=
r then turns into action. What is the &quot;intent&quot; of writing:</div><=
div><br></div><div><font face=3D"monospace, monospace">constexpr(some_test(=
)) int sqr(int n);</font>=C2=A0</div><div><br></div><div>?</div><div><br></=
div><div>What could some_test() possibly be testing? Why would it matter? T=
he implementation of sqr is either a constexpr expression or it&#39;s not. =
If it is, its constexpr-ness can be undone by the context of its use (becau=
se it takes an argument). What&#39;s wrong with that?</div><div><br></div><=
div><br></div></div></div></blockquote><div><br></div><div><div>The main mo=
tivation=C2=A0for my post was=C2=A0I=C2=A0wasn&#39;t hot for=C2=A0the !=C2=
=A0syntax=C2=A0in constexpr!.=C2=A0constexpr(true) seems more c++-ish to me=
..</div><div>I can&#39;t myself see any reason to want to conditionally cons=
texpr some function but the non ! syntax doesn&#39;t shut any doors=C2=A0if=
=C2=A0people later did find a use case.</div><div>I wouldn&#39;t be despera=
tely unhappy with constexpr! though.</div></div><div><br></div><div>But I&#=
39;d like to see inline get the same treatment. So we get=C2=A0__forceinlin=
e standardized and it seems it should be consistent with the constexpr synt=
ax,</div><div>There I can imagine <font face=3D"monospace, monospace">inlin=
e(some_test()) int sqr(int n);</font>=C2=A0might be more useful, but I&#39;=
m not sure.</div><div>some_test() might return a different value based=C2=
=A0on some compilers=C2=A0ability to inline in a desirable way or not.</div=
><div>But even there in reality I imagine people will #if different functio=
ns anyway if that was the case.</div><div><br></div><div>__forceline being =
standardized as inline(true) or inline! is the main thing.</div><div>And=C2=
=A0if there was a use for inline(some_condition()) then it seems constexpr(=
true) would be the better syntax to match it even if no real expression is =
supported.</div><div><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" 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/67f9b892-ea8d-43ab-aa42-9e225bcbbbac%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/67f9b892-ea8d-43ab-aa42-9e225bcbbbac%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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/CALmDwq2fJ2_tUJa13BWkOACnHqDqJM2q8Bfc=
t2TqCyvsKnDLRg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2fJ2_tUJa1=
3BWkOACnHqDqJM2q8Bfct2TqCyvsKnDLRg%40mail.gmail.com</a>.<br />

--0000000000000fd6fc0570a3deec--

.

--0000000000001c27eb0570a3fbe1
Content-Type: text/plain; charset="UTF-8"

On Tue, 10 Jul 2018, 12:59 Nicolas Lesser, <blitzrakete@gmail.com> wrote:

> But that's just my opinion.
>

Mine too.

The exclamation mark is ugly but its intent is clear. If there's a good
reason to allow control over whether a method is constexpr or constexpr!
based on the outcome of another constexpr function, then constexpr(bool) is
doable, but it hangs on that.

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

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

<div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">=
On Tue, 10 Jul 2018, 12:59 Nicolas Lesser, &lt;<a href=3D"mailto:blitzraket=
e@gmail.com">blitzrakete@gmail.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">But that&#39;s just my o=
pinion.<br></div></div></blockquote></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Mine too.</div><div dir=3D"auto"><br></div><div dir=3D"auto">T=
he exclamation mark is ugly but its intent is clear. If there&#39;s a good =
reason to allow control over whether a method is constexpr or constexpr! ba=
sed on the outcome of another constexpr function, then constexpr(bool) is d=
oable, but it hangs on that.</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/CAC%2B0CCPNETKMtBZAVruh%3D-SsgjBsRe7C=
iBcy9jbY9hhmjkjSHw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPNET=
KMtBZAVruh%3D-SsgjBsRe7CiBcy9jbY9hhmjkjSHw%40mail.gmail.com</a>.<br />

--0000000000001c27eb0570a3fbe1--

.

------=_Part_508_1442704176.1533277185196
Content-Type: multipart/alternative;
 boundary="----=_Part_509_1248835167.1533277185196"

------=_Part_509_1248835167.1533277185196
Content-Type: text/plain; charset="UTF-8"

The constexpr will need to go after the parameters, so that it can express
a condition that is dependent on the actual value of the parameters. An
example is to control recursion. Perhaps:

auto factorial(int n)->int constexpr(n<100) {
   if(n==0) return 1;
   else return n*factorial(n-1);
}

On Monday, July 9, 2018 at 8:04:11 PM UTC-4, gmis...@gmail.com wrote:

> Hello everyone
>
> Have the authors of p10731r.html considered if this suggestion:
>
> constexpr(true) int sqr(int n) {
>   return n*n;
> }
>
> is preferable and more consistent or flexible than this which they
> currently propose:
>
> constexpr! int sqr(int n) {
>   return n*n;
> }
>
> And would it offer the following possibility and would it be useful?:
>
> constexpr(some_condition()) int sqr(int n) { // constexpr this function on
> certain conditions.
>   return n*n;
> }
>
> Also many compilers support forceinline functionality etc. Perhaps this
> should be standardized too now?
> Therefore I think the authors might want to propose this too:
>
> inline(false) int sqr(int n) { // force inline. Or inline! if the
> committee thinks best.
>   return n*n;
> }
>
> Which might similarly allow this?:
> inline(some_other_condiition()) int sqr(int n) { // force inline. Or
> inline! if the committee thinks best.
>   return n*n;
> }
>
> where some_other_condition might test for a certain platform or compile
> where forcing inline or not might be desirable despite what the compiler
> thinks.
>
> It seems to me using ! is a little unusual syntax and be less consistent
> and flexible than what I'm proposing but I admit ! is shorter.
>
> I see such macros regarding forceinline in various code bases such as
> libcxx's __config file. So perhaps forceinline's time has come too.
>
> What do the authors of p1073r1 and others think?
>
> Thanks
> Show trimmed content
> Click here to Reply
>

--
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/1c719172-4ea9-4cfc-b491-d1c7da7ccaac%40isocpp.org.

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

<div dir=3D"ltr">The constexpr will need to go after the parameters, so tha=
t it can express a condition that is dependent on the actual value of the p=
arameters. An example is to control recursion. Perhaps:<div><br></div><div>=
auto factorial(int n)-&gt;int constexpr(n&lt;100) {</div><div>=C2=A0 =C2=A0=
if(n=3D=3D0) return 1;</div><div>=C2=A0 =C2=A0else return n*factorial(n-1);=
<br>}<br><div><div><br></div><div>On Monday, July 9, 2018 at 8:04:11 PM UTC=
-4, gmis...@gmail.com wrote:<br></div><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 style=3D"max-height:10000px"><div dir=3D=
"ltr"><div>Hello everyone</div><div><br>Have the authors of=C2=A0p10731r.ht=
ml considered if this suggestion:</div><div><br></div><p>constexpr(true) in=
t sqr(int n) {<br>=C2=A0 return n*n;<br>}</p><div><br></div><div>is prefera=
ble and more consistent or flexible than this which=C2=A0they currently pro=
pose:</div><div><br></div><div>constexpr! int sqr(int n) {<br>=C2=A0 return=
 n*n;<br>}</div><div><br></div><div>And would=C2=A0it offer=C2=A0the follow=
ing=C2=A0possibility and would it be useful?:</div><div><br></div><div>cons=
texpr(some_condition()) int sqr(int n) { //=C2=A0constexpr this function=C2=
=A0on certain=C2=A0conditions.<br>=C2=A0 return n*n;<br>}</div><div><br>Als=
o=C2=A0many compilers support=C2=A0forceinline functionality etc. Perhaps t=
his should be standardized too now?</div><div>Therefore I think the authors=
 might want to=C2=A0propose this too:</div><div><br></div><div>inline(false=
) int sqr(int n) { // force inline. Or inline! if the committee thinks best=
..<br>=C2=A0 return n*n;<br>}</div><div><br></div><div>Which might similarly=
 allow this?:</div><div>inline(some_other_condiition()<wbr>) int sqr(int n)=
 { // force inline. Or inline! if the committee thinks best.<br>=C2=A0 retu=
rn n*n;<br>}</div><div><br></div><div>where some_other_condition might=C2=
=A0test for a certain platform or compile where forcing inline or not might=
 be desirable despite what the compiler thinks.</div><div><br></div><div>It=
 seems to me using ! is a little unusual syntax=C2=A0and be less consistent=
 and flexible than what I&#39;m proposing but=C2=A0I admit ! is shorter.</d=
iv><div><div><br></div><div>I see such macros regarding forceinline in vari=
ous code bases such as libcxx&#39;s __config file. So perhaps forceinline&#=
39;s time has come too.</div></div><div><br></div><div>What do the authors =
of=C2=A0p1073r1 and others think?</div><div><br></div><div>Thanks<br></div>=
</div></div><a style=3D"display:none">Show trimmed content</a> <div style=
=3D"display:none"><div></div></div><div></div><div></div><div style=3D"disp=
lay:none"></div><div style=3D"display:none"></div><div><div></div></div><di=
v><div><div><div style=3D"display:inline-block"><div style=3D"display:none"=
></div></div> <div><div>Click here to <span>Reply</span></div></div></div><=
/div></div></div></blockquote></div></div></div></div>

<p></p>

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

------=_Part_509_1248835167.1533277185196--

------=_Part_508_1442704176.1533277185196--

.

--000000000000e917ed05728902ad
Content-Type: text/plain; charset="UTF-8"

Why would one need to have a function that is conditionally constexpr!?

On Thu, Aug 2, 2018 at 11:19 PM <chatham130@gmail.com> wrote:

> The constexpr will need to go after the parameters, so that it can express
> a condition that is dependent on the actual value of the parameters. An
> example is to control recursion. Perhaps:
>
> auto factorial(int n)->int constexpr(n<100) {
>    if(n==0) return 1;
>    else return n*factorial(n-1);
> }
>
> On Monday, July 9, 2018 at 8:04:11 PM UTC-4, gmis...@gmail.com wrote:
>
>> Hello everyone
>>
>> Have the authors of p10731r.html considered if this suggestion:
>>
>> constexpr(true) int sqr(int n) {
>>   return n*n;
>> }
>>
>> is preferable and more consistent or flexible than this which they
>> currently propose:
>>
>> constexpr! int sqr(int n) {
>>   return n*n;
>> }
>>
>> And would it offer the following possibility and would it be useful?:
>>
>> constexpr(some_condition()) int sqr(int n) { // constexpr this
>> function on certain conditions.
>>   return n*n;
>> }
>>
>> Also many compilers support forceinline functionality etc. Perhaps this
>> should be standardized too now?
>> Therefore I think the authors might want to propose this too:
>>
>> inline(false) int sqr(int n) { // force inline. Or inline! if the
>> committee thinks best.
>>   return n*n;
>> }
>>
>> Which might similarly allow this?:
>> inline(some_other_condiition()) int sqr(int n) { // force inline. Or
>> inline! if the committee thinks best.
>>   return n*n;
>> }
>>
>> where some_other_condition might test for a certain platform or compile
>> where forcing inline or not might be desirable despite what the compiler
>> thinks.
>>
>> It seems to me using ! is a little unusual syntax and be less consistent
>> and flexible than what I'm proposing but I admit ! is shorter.
>>
>> I see such macros regarding forceinline in various code bases such as
>> libcxx's __config file. So perhaps forceinline's time has come too.
>>
>> What do the authors of p1073r1 and others think?
>>
>> Thanks
>> Show trimmed content
>> Click here to Reply
>>
> --
> 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/1c719172-4ea9-4cfc-b491-d1c7da7ccaac%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1c719172-4ea9-4cfc-b491-d1c7da7ccaac%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/CALmDwq0skNY43NToFiQwKpvTwUSv0XWuSuRA1yEFq-A5MreK1w%40mail.gmail.com.

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

<div dir=3D"ltr">Why would one need to have a function that is conditionall=
y constexpr!?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, =
Aug 2, 2018 at 11:19 PM &lt;<a href=3D"mailto:chatham130@gmail.com">chatham=
130@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">The constexpr will need to go after the parameters, so that it c=
an express a condition that is dependent on the actual value of the paramet=
ers. An example is to control recursion. Perhaps:<div><br></div><div>auto f=
actorial(int n)-&gt;int constexpr(n&lt;100) {</div><div>=C2=A0 =C2=A0if(n=
=3D=3D0) return 1;</div><div>=C2=A0 =C2=A0else return n*factorial(n-1);<br>=
}<br><div><div><br></div><div>On Monday, July 9, 2018 at 8:04:11 PM UTC-4, =
<a href=3D"mailto:gmis...@gmail.com" target=3D"_blank">gmis...@gmail.com</a=
> wrote:<br></div><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 style=3D"max-height:10000px"><div dir=3D"ltr"><div>Hello everyone=
</div><div><br>Have the authors of=C2=A0p10731r.html considered if this sug=
gestion:</div><div><br></div><p>constexpr(true) int sqr(int n) {<br>=C2=A0 =
return n*n;<br>}</p><div><br></div><div>is preferable and more consistent o=
r flexible than this which=C2=A0they currently propose:</div><div><br></div=
><div>constexpr! int sqr(int n) {<br>=C2=A0 return n*n;<br>}</div><div><br>=
</div><div>And would=C2=A0it offer=C2=A0the following=C2=A0possibility and =
would it be useful?:</div><div><br></div><div>constexpr(some_condition()) i=
nt sqr(int n) { //=C2=A0constexpr this function=C2=A0on certain=C2=A0condit=
ions.<br>=C2=A0 return n*n;<br>}</div><div><br>Also=C2=A0many compilers sup=
port=C2=A0forceinline functionality etc. Perhaps this should be standardize=
d too now?</div><div>Therefore I think the authors might want to=C2=A0propo=
se this too:</div><div><br></div><div>inline(false) int sqr(int n) { // for=
ce inline. Or inline! if the committee thinks best.<br>=C2=A0 return n*n;<b=
r>}</div><div><br></div><div>Which might similarly allow this?:</div><div>i=
nline(some_other_condiition()) int sqr(int n) { // force inline. Or inline!=
 if the committee thinks best.<br>=C2=A0 return n*n;<br>}</div><div><br></d=
iv><div>where some_other_condition might=C2=A0test for a certain platform o=
r compile where forcing inline or not might be desirable despite what the c=
ompiler thinks.</div><div><br></div><div>It seems to me using ! is a little=
 unusual syntax=C2=A0and be less consistent and flexible than what I&#39;m =
proposing but=C2=A0I admit ! is shorter.</div><div><div><br></div><div>I se=
e such macros regarding forceinline in various code bases such as libcxx&#3=
9;s __config file. So perhaps forceinline&#39;s time has come too.</div></d=
iv><div><br></div><div>What do the authors of=C2=A0p1073r1 and others think=
?</div><div><br></div><div>Thanks<br></div></div></div><a style=3D"display:=
none">Show trimmed content</a> <div style=3D"display:none"><div></div></div=
><div></div><div></div><div style=3D"display:none"></div><div style=3D"disp=
lay:none"></div><div><div></div></div><div><div><div><div style=3D"display:=
inline-block"><div style=3D"display:none"></div></div> <div><div>Click here=
 to <span>Reply</span></div></div></div></div></div></div></blockquote></di=
v></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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/1c719172-4ea9-4cfc-b491-d1c7da7ccaac%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1c719172-4ea9-=
4cfc-b491-d1c7da7ccaac%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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/CALmDwq0skNY43NToFiQwKpvTwUSv0XWuSuRA=
1yEFq-A5MreK1w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq0skNY43NTo=
FiQwKpvTwUSv0XWuSuRA1yEFq-A5MreK1w%40mail.gmail.com</a>.<br />

--000000000000e917ed05728902ad--

.

--00000000000077ec7405728bf817
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 10, 2018 at 7:59 AM, Nicolas Lesser <blitzrakete@gmail.com>
wrote:

> I don't like this syntax because it is too similar to the noexcept
> operator and explicit bool, while being too dissimilar to the effects of
> those two.
>

Exactly.  keyword(boolean) is becoming a pattern.  And keyword(true) means
the same as keyword.

I don't see anything compelling enough to break that pattern.


--
Be seeing you,
Tony

--
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/CAOHCbisEnfZJbf4tS74J%2BonZix0sqi-FhpXcLpcaTnAb78oTpA%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Jul 10, 2018 at 7:59 AM, Nicolas Lesser <span dir=3D"ltr">&lt;<=
a href=3D"mailto:blitzrakete@gmail.com" target=3D"_blank">blitzrakete@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"au=
to">I don&#39;t like this syntax because it is too similar to the noexcept =
operator and explicit bool, while being too dissimilar to the effects of th=
ose two.</div></blockquote><div><br></div><div>Exactly.=C2=A0 keyword(boole=
an) is becoming a pattern.=C2=A0 And keyword(true) means the same as keywor=
d.</div><div><br></div>I don&#39;t see anything compelling enough to break =
that pattern.<br></div><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

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

--00000000000077ec7405728bf817--

.

------=_Part_1181_1215522536.1534025607955
Content-Type: multipart/alternative;
 boundary="----=_Part_1182_1634764540.1534025607955"

------=_Part_1182_1634764540.1534025607955
Content-Type: text/plain; charset="UTF-8"

 i wonder. How to need compiletime culc phase...

ex . constexpr(some_condition()) int sqr(int n){}

this needs 2 phase.
first to calc some_conditon()// is this finish one phase?
second to calc needed function.

can you description the order of decision.
at me not mind to force inline.
optimizer compiler is too canning then beginner.
what do you think the usecase.

--
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/5e0bbfcf-c60c-46e8-963f-3447b3b08fcc%40isocpp.org.

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

<div dir=3D"ltr"><div>=C2=A0<span style=3D"display: inline !important; floa=
t: none; background-color: transparent; color: rgb(34, 34, 34); font-family=
: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font=
-style: normal; font-variant: normal; font-weight: 400; letter-spacing: nor=
mal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px;=
 text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal;=
 word-spacing: 0px;">i wonder. How to need compiletime culc phase...</span>=
<br></div><div><br></div><div>ex .=C2=A0<span style=3D"display: inline !imp=
ortant; float: none; background-color: transparent; color: rgb(34, 34, 34);=
 font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size=
: 13px; font-style: normal; font-variant: normal; font-weight: 400; letter-=
spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-=
indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-sp=
ace: normal; word-spacing: 0px;">constexpr(some_condition()) int sqr(int n)=
{}</span></div><div><span style=3D"display: inline !important; float: none;=
 background-color: transparent; color: rgb(34, 34, 34); font-family: &quot;=
Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: =
normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orp=
hans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-tr=
ansform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-sp=
acing: 0px;"><br></span></div><div>this needs 2 phase.</div><div>first to c=
alc some_conditon()// is this finish one phase?</div><div>second to calc ne=
eded function.</div><div><br></div><div>can you description the order of de=
cision.</div><div>at me not mind to force inline.</div><div>optimizer compi=
ler is too canning then beginner.</div><div>what do you think the usecase.<=
/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/5e0bbfcf-c60c-46e8-963f-3447b3b08fcc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5e0bbfcf-c60c-46e8-963f-3447b3b08fcc=
%40isocpp.org</a>.<br />

------=_Part_1182_1634764540.1534025607955--

------=_Part_1181_1215522536.1534025607955--

.