Topic: Design question: if constexpr (aka. constexpr
Author: TONGARI J <tongari95@gmail.com>
Date: Sat, 12 Mar 2016 02:11:28 -0800 (PST)
Raw View
------=_Part_3737_302655625.1457777488432
Content-Type: multipart/alternative;
boundary="----=_Part_3738_335897919.1457777488432"
------=_Part_3738_335897919.1457777488432
Content-Type: text/plain; charset=UTF-8
I just read Herb Sutter's trip report
<http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-meeting/>,
in the post he said that the committee changed the syntax to `if constexpr`.
I also read the original paper p0128r1
<http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0128r1.html>, it was
`constexpr if` in the paper (somewhat still with ugly `constexpr_else
` counterpart).
Whether it is `if constexpr`/`constexpr if`/`constexpr_if`, I wonder why
couldn't it just be `if`?
After all, the compiler knows the expression is constexpr or not, why
should we bother to specify constexpr explicitly?
And since the proposed constexpr_if is a very restrictive form of `static
if`, in that it could only be applied where the normal `if` is allowed, why
not just extend the normal `if` to support the desired behavior? At least
it won't break existing code.
Do we really need a keyword for that? I don't see the rationale explained
anywhere in the proposal.
--
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/2bed5c99-81cd-4061-a58d-ba1b3cbbf872%40isocpp.org.
------=_Part_3738_335897919.1457777488432
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I just re<font color=3D"#000000">ad Herb Sutter's</fon=
t> <a href=3D"http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-sta=
ndards-meeting/">trip report</a>, in the post he said that the committee ch=
anged the syntax to `if constexpr`.<br><div>I also read the original=C2=A0p=
aper <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0128r1=
..html">p0128r1</a>, it was `constexpr if` in the paper (somewhat still with=
ugly `<span style=3D"color: rgb(0, 0, 0);">constexpr_else</span>`=C2=A0cou=
nterpart).</div><div>Whether it is `if constexpr`/`constexpr if`/`constexpr=
_if`, I wonder why couldn't it just be `if`?</div><div><br></div><div>A=
fter all, the compiler knows the expression is constexpr or not, why should=
we bother to specify constexpr explicitly?</div><div>And since the propose=
d constexpr_if is a very restrictive form of `static if`, in that it could =
only be applied where the normal `if` is allowed, why not just extend the=
=C2=A0normal=C2=A0`if` to support the desired behavior? At least it won'=
;t break existing code.</div><div><br></div><div>Do we really need a=C2=A0k=
eyword for that? I don't see the rationale explained anywhere in the pr=
oposal.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2bed5c99-81cd-4061-a58d-ba1b3cbbf872%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2bed5c99-81cd-4061-a58d-ba1b3cbbf872=
%40isocpp.org</a>.<br />
------=_Part_3738_335897919.1457777488432--
------=_Part_3737_302655625.1457777488432--
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Sat, 12 Mar 2016 11:32:44 +0100
Raw View
On 03/12/2016 11:11 AM, TONGARI J wrote:
> I just read Herb Sutter's trip report <http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-meeting/>, in the post he said that the committee changed the syntax to `if constexpr`.
> I also read the original paper p0128r1 <http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0128r1.html>, it was `constexpr if` in the paper (somewhat still with ugly `constexpr_else` counterpart).
> Whether it is `if constexpr`/`constexpr if`/`constexpr_if`, I wonder why couldn't it just be `if`?
>
> After all, the compiler knows the expression is constexpr or not, why should we bother to specify constexpr explicitly?
> And since the proposed constexpr_if is a very restrictive form of `static if`, in that it could only be applied where the normal `if` is allowed, why not just extend the normal `if` to support the desired behavior? At least it won't break existing code.
>
> Do we really need a keyword for that? I don't see the rationale explained anywhere in the proposal.
At the very least, the "constexpr" keyword adds the assertion
that the condition is actually a constant expression.
Since you get different instantiation behavior with a constant
expression vs. a run-time "if", it seems prudent to spell the
programmer intent and assertion explicitly in code (and getting
an error early) rather than waiting until some nested
instantiation in a non-taken branch of a supposedly-constexpr
"if" fails mysteriously.
As a weak analogy, we require "constexpr" for variables of class
type when they are supposed to be used inside constant expressions,
even though "const" would suffice from a technical standpoint.
Jens
--
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/56E3F04C.2050203%40gmx.net.
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Sat, 12 Mar 2016 11:43:39 -0800 (PST)
Raw View
------=_Part_2994_342873229.1457811819193
Content-Type: multipart/alternative;
boundary="----=_Part_2995_1086228144.1457811819194"
------=_Part_2995_1086228144.1457811819194
Content-Type: text/plain; charset=UTF-8
On Saturday, March 12, 2016 at 5:11:28 AM UTC-5, TONGARI J wrote:
>
> I just read Herb Sutter's trip report
> <http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-meeting/>,
> in the post he said that the committee changed the syntax to `if constexpr`.
> I also read the original paper p0128r1
> <http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0128r1.html>, it
> was `constexpr if` in the paper (somewhat still with ugly `constexpr_else
> ` counterpart).
> Whether it is `if constexpr`/`constexpr if`/`constexpr_if`, I wonder why
> couldn't it just be `if`?
>
> After all, the compiler knows the expression is constexpr or not, why
> should we bother to specify constexpr explicitly?
> And since the proposed constexpr_if is a very restrictive form of `static
> if`, in that it could only be applied where the normal `if` is allowed, why
> not just extend the normal `if` to support the desired behavior? At least
> it won't break existing code.
>
> Do we really need a keyword for that? I don't see the rationale explained
> anywhere in the proposal.
>
if(can_do_something())
{
do_something();
}
else
{
do_something_else();
}
If optimization is enabled, the compiler MAY attempt to see if
can_do_something() produces a constant, and if so may eliminate one branch
or the other. If it can't, it outputs the test and both calls, so both
calls must compile without error.
if constexpr(can_do_something())
{
do_something();
}
else
{
do_something_else();
}
The compiler MUST evaluate can_do_something() to produce a constant,
eliminate the test, and only instantiate one of the two calls based on the
value of the constant. In this case, only the selected branch has to
compile without error.
--
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/807ebb70-03e4-415a-8337-832cedd263a2%40isocpp.org.
------=_Part_2995_1086228144.1457811819194
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, March 12, 2016 at 5:11:28 AM UTC-5, TONGARI J=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I just=
re<font color=3D"#000000">ad Herb Sutter's</font> <a href=3D"http://he=
rbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-meeting/" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\75http%3A%2F%2Fherbsutter.com%2F2016%2F03%2F11%2Ftrip-report-=
winter-iso-c-standards-meeting%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNFZ3B3a=
9QEjcfgwYx8CEw1gJTtchA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fherbsutter.com%2F2016%2F03%2F11%2Ftri=
p-report-winter-iso-c-standards-meeting%2F\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNFZ3B3a9QEjcfgwYx8CEw1gJTtchA';return true;">trip report</a>, in the =
post he said that the committee changed the syntax to `if constexpr`.<br><d=
iv>I also read the original=C2=A0paper <a href=3D"http://open-std.org/JTC1/=
SC22/WG21/docs/papers/2016/p0128r1.html" target=3D"_blank" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2=
Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2016%2Fp0128r1.html\46=
sa\75D\46sntz\0751\46usg\75AFQjCNG7AVdIkDdcZg2ExoN6TcN81-l8hw';return t=
rue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%=
2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2016%2Fp0128r1.html\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNG7AVdIkDdcZg2ExoN6TcN81-l8hw';return =
true;">p0128r1</a>, it was `constexpr if` in the paper (somewhat still with=
ugly `<span style=3D"color:rgb(0,0,0)">constexpr_else</span>`=C2=A0counter=
part).</div><div>Whether it is `if constexpr`/`constexpr if`/`constexpr_if`=
, I wonder why couldn't it just be `if`?</div><div><br></div><div>After=
all, the compiler knows the expression is constexpr or not, why should we =
bother to specify constexpr explicitly?</div><div>And since the proposed co=
nstexpr_if is a very restrictive form of `static if`, in that it could only=
be applied where the normal `if` is allowed, why not just extend the=C2=A0=
normal=C2=A0`if` to support the desired behavior? At least it won't bre=
ak existing code.</div><div><br></div><div>Do we really need a=C2=A0keyword=
for that? I don't see the rationale explained anywhere in the proposal=
..</div></div></blockquote><div><br></div><div>if(can_do_something())</div><=
div>{</div><div>=C2=A0 =C2=A0 do_something();</div><div>}<br></div><div>els=
e</div><div>{</div><div>=C2=A0 =C2=A0 do_something_else();</div><div>}<br><=
/div><div><br></div><div>If optimization is enabled, the compiler MAY attem=
pt to see if can_do_something() produces a constant, and if so may eliminat=
e one branch or the other. =C2=A0If it can't, it outputs the test and b=
oth calls, so both calls must compile without error.</div><div><br></div><d=
iv>if constexpr(can_do_something())</div><div>{</div><div>=C2=A0 =C2=A0 do_=
something();</div><div>}<br></div><div>else</div><div>{</div><div>=C2=A0 =
=C2=A0 do_something_else();</div><div>}<br></div><div><br></div><div>The co=
mpiler MUST evaluate can_do_something() to produce a constant, eliminate th=
e test, and only instantiate one of the two calls based on the value of the=
constant. =C2=A0In this case, only the selected branch has to compile with=
out error.</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" 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/807ebb70-03e4-415a-8337-832cedd263a2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/807ebb70-03e4-415a-8337-832cedd263a2=
%40isocpp.org</a>.<br />
------=_Part_2995_1086228144.1457811819194--
------=_Part_2994_342873229.1457811819193--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 12 Mar 2016 21:51:47 +0200
Raw View
On 12 March 2016 at 21:43, Greg Marr <gregmmarr@gmail.com> wrote:
>> Do we really need a keyword for that? I don't see the rationale explained
>> anywhere in the proposal.
>
>
> if(can_do_something())
> {
> do_something();
> }
> else
> {
> do_something_else();
> }
>
> If optimization is enabled, the compiler MAY attempt to see if
> can_do_something() produces a constant, and if so may eliminate one branch
> or the other. If it can't, it outputs the test and both calls, so both
> calls must compile without error.
Regardless of whether optimization is enabled, I know that the
compiler will check the full validity
of the else-branch, so it can't contain any 'nonsense', even if it's
dependent 'nonsense'. Making
an if do the same thing as if constexpr would lose that guarantee.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUao1cLPZDeNvmaeecqj2LbrarT4eNX5%3DZwD2GL-VHDDMw%40mail.gmail.com.
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Sat, 12 Mar 2016 12:26:33 -0800 (PST)
Raw View
------=_Part_191_1340490994.1457814393883
Content-Type: multipart/alternative;
boundary="----=_Part_192_781653567.1457814393883"
------=_Part_192_781653567.1457814393883
Content-Type: text/plain; charset=UTF-8
On Saturday, March 12, 2016 at 2:51:50 PM UTC-5, Ville Voutilainen wrote:
>
> On 12 March 2016 at 21:43, Greg Marr <greg...@gmail.com <javascript:>>
> wrote:
> >> Do we really need a keyword for that? I don't see the rationale
> explained
> >> anywhere in the proposal.
> >
> >
> > if(can_do_something())
> > {
> > do_something();
> > }
> > else
> > {
> > do_something_else();
> > }
> >
> > If optimization is enabled, the compiler MAY attempt to see if
> > can_do_something() produces a constant, and if so may eliminate one
> branch
> > or the other. If it can't, it outputs the test and both calls, so both
> > calls must compile without error.
>
>
> Regardless of whether optimization is enabled, I know that the
> compiler will check the full validity
> of the else-branch, so it can't contain any 'nonsense', even if it's
> dependent 'nonsense'.
Yes, that's what I was trying to express, but it may not have been clear.
Thanks for the clarification.
--
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/690cb036-f814-40c1-8103-77f457541071%40isocpp.org.
------=_Part_192_781653567.1457814393883
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, March 12, 2016 at 2:51:50 PM UTC-5, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12 March 201=
6 at 21:43, Greg Marr <<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"dXr2XL6VBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">greg...@gmail.com</a>> wrote:
<br>>> Do we really need a keyword for that? I don't see the rati=
onale explained
<br>>> anywhere in the proposal.
<br>>
<br>>
<br>> if(can_do_something())
<br>> {
<br>> =C2=A0 =C2=A0 do_something();
<br>> }
<br>> else
<br>> {
<br>> =C2=A0 =C2=A0 do_something_else();
<br>> }
<br>>
<br>> If optimization is enabled, the compiler MAY attempt to see if
<br>> can_do_something() produces a constant, and if so may eliminate on=
e branch
<br>> or the other. =C2=A0If it can't, it outputs the test and both =
calls, so both
<br>> calls must compile without error.
<br>
<br>
<br>Regardless of whether optimization is enabled, I know that the
<br>compiler will check the full validity
<br>of the else-branch, so it can't contain any 'nonsense', eve=
n if it's
<br>dependent 'nonsense'.</blockquote><div><br></div><div>Yes, that=
's what I was trying to express, but it may not have been clear.</div><=
div>Thanks for the clarification.=C2=A0</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" 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/690cb036-f814-40c1-8103-77f457541071%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/690cb036-f814-40c1-8103-77f457541071=
%40isocpp.org</a>.<br />
------=_Part_192_781653567.1457814393883--
------=_Part_191_1340490994.1457814393883--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Sat, 12 Mar 2016 21:53:38 -0800 (PST)
Raw View
------=_Part_4407_52130229.1457848418126
Content-Type: multipart/alternative;
boundary="----=_Part_4408_1051103553.1457848418126"
------=_Part_4408_1051103553.1457848418126
Content-Type: text/plain; charset=UTF-8
On Sunday, March 13, 2016 at 3:51:50 AM UTC+8, Ville Voutilainen wrote:
>
> On 12 March 2016 at 21:43, Greg Marr <greg...@gmail.com <javascript:>>
> wrote:
> >> Do we really need a keyword for that? I don't see the rationale
> explained
> >> anywhere in the proposal.
> >
> >
> > if(can_do_something())
> > {
> > do_something();
> > }
> > else
> > {
> > do_something_else();
> > }
> >
> > If optimization is enabled, the compiler MAY attempt to see if
> > can_do_something() produces a constant, and if so may eliminate one
> branch
> > or the other. If it can't, it outputs the test and both calls, so both
> > calls must compile without error.
>
>
> Regardless of whether optimization is enabled, I know that the
> compiler will check the full validity
> of the else-branch, so it can't contain any 'nonsense', even if it's
> dependent 'nonsense'. Making
> an if do the same thing as if constexpr would lose that guarantee.
>
This code:
struct A{};
template<bool flag>
void f()
{
A a;
a.f(); // error: no member named 'f'
}
will generate error with clang & g++ without instantiating the template
even though it's not required by the standard.
Does your proposal tend to allow the compiler to emit diagnostic in the
example:
template<bool flag>
void f()
{
if constexpr (flag)
{
A a;
a.f();
}
}
?
I'm not suggesting changing `if` in non-template context, what I'd like to
see is allowing `if` to behave as the proposed `if constexpr` when it's in
template and the condition is a dependent-expression. This way, you still
get the traditional `if` guarantee in normal case, and you get the desired
lazy-evaluation in generic case, and the diagnostic in the above example is
still allowed.
Remember the early day when we're not yet familiar with TMP, this is what a
beginner would expect for `if` intuitively, so why not just extend `if` to
match the expectation?
--
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/15ddea74-50e1-427a-84cd-7c2707ac55a5%40isocpp.org.
------=_Part_4408_1051103553.1457848418126
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, March 13, 2016 at 3:51:50 AM UTC+8, Ville Vouti=
lainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12 March 2016 =
at 21:43, Greg Marr <<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"dXr2XL6VBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&=
#39;;return true;">greg...@gmail.com</a>> wrote:
<br>>> Do we really need a keyword for that? I don't see the rati=
onale explained
<br>>> anywhere in the proposal.
<br>>
<br>>
<br>> if(can_do_something())
<br>> {
<br>> =C2=A0 =C2=A0 do_something();
<br>> }
<br>> else
<br>> {
<br>> =C2=A0 =C2=A0 do_something_else();
<br>> }
<br>>
<br>> If optimization is enabled, the compiler MAY attempt to see if
<br>> can_do_something() produces a constant, and if so may eliminate on=
e branch
<br>> or the other. =C2=A0If it can't, it outputs the test and both =
calls, so both
<br>> calls must compile without error.
<br>
<br>
<br>Regardless of whether optimization is enabled, I know that the
<br>compiler will check the full validity
<br>of the else-branch, so it can't contain any 'nonsense', eve=
n if it's
<br>dependent 'nonsense'. Making
<br>an if do the same thing as if constexpr would lose that guarantee.
<br></blockquote><div><br></div><div>This code:</div><div class=3D"prettypr=
int" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; =
background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> A</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> flag</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 A a</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 a</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// error: no member named &#=
39;f'</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></span></div=
></code></div><div><br></div><div>will generate error with clang & g++ =
without instantiating the template even though it's not required by the=
standard.</div><div><br></div><div>Does your proposal tend to allow the co=
mpiler to emit diagnostic in the example:</div><div><div class=3D"prettypri=
nt" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; b=
ackground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> flag</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">constexpr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">flag</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A=
a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
=C2=A0 =C2=A0 a</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div=
><div>?</div></div><div><br></div><div>I'm not suggesting changing `if`=
in non-template context, what I'd like to see is allowing `if` to beha=
ve as the proposed `if constexpr` when it's in template and the conditi=
on is a dependent-expression. This way, you still get the traditional `if` =
guarantee in normal case, and you get the desired lazy-evaluation in generi=
c case, and the diagnostic in the above example is still allowed.</div><div=
><br></div><div>Remember the early day when we're not yet familiar with=
TMP, this is what a beginner would expect for `if` intuitively, so why not=
just extend `if` to match the expectation?</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/15ddea74-50e1-427a-84cd-7c2707ac55a5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/15ddea74-50e1-427a-84cd-7c2707ac55a5=
%40isocpp.org</a>.<br />
------=_Part_4408_1051103553.1457848418126--
------=_Part_4407_52130229.1457848418126--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 13 Mar 2016 06:41:57 -0700 (PDT)
Raw View
------=_Part_3356_1309773436.1457876517277
Content-Type: multipart/alternative;
boundary="----=_Part_3357_2099121564.1457876517278"
------=_Part_3357_2099121564.1457876517278
Content-Type: text/plain; charset=UTF-8
On Sunday, March 13, 2016 at 12:53:38 AM UTC-5, TONGARI J wrote:
>
> On Sunday, March 13, 2016 at 3:51:50 AM UTC+8, Ville Voutilainen wrote:
>>
>> On 12 March 2016 at 21:43, Greg Marr <greg...@gmail.com> wrote:
>> >> Do we really need a keyword for that? I don't see the rationale
>> explained
>> >> anywhere in the proposal.
>> >
>> >
>> > if(can_do_something())
>> > {
>> > do_something();
>> > }
>> > else
>> > {
>> > do_something_else();
>> > }
>> >
>> > If optimization is enabled, the compiler MAY attempt to see if
>> > can_do_something() produces a constant, and if so may eliminate one
>> branch
>> > or the other. If it can't, it outputs the test and both calls, so both
>> > calls must compile without error.
>>
>>
>> Regardless of whether optimization is enabled, I know that the
>> compiler will check the full validity
>> of the else-branch, so it can't contain any 'nonsense', even if it's
>> dependent 'nonsense'. Making
>> an if do the same thing as if constexpr would lose that guarantee.
>>
>
> This code:
> struct A{};
>
> template<bool flag>
> void f()
> {
> A a;
> a.f(); // error: no member named 'f'
> }
>
> will generate error with clang & g++ without instantiating the template
> even though it's not required by the standard.
>
> Does your proposal tend to allow the compiler to emit diagnostic in the
> example:
> template<bool flag>
> void f()
> {
> if constexpr (flag)
> {
> A a;
> a.f();
> }
> }
> ?
>
> I'm not suggesting changing `if` in non-template context, what I'd like to
> see is allowing `if` to behave as the proposed `if constexpr` when it's in
> template and the condition is a dependent-expression. This way, you still
> get the traditional `if` guarantee in normal case, and you get the desired
> lazy-evaluation in generic case, and the diagnostic in the above example is
> still allowed.
>
See, the problem is that the expression doesn't just have to be a
"dependent-expression". It must be a dependent expression which can be
evaluated at compile time. A function call can be a dependent-expression,
but unless that function is `constexpr`, the compiler can't do anything
with it.
That's why it's a good idea to put `constexpr` in the condition. It tells
the user what they have to do in order to make the code work, and it tells
the user that they will get special behavior by doing so.
> Remember the early day when we're not yet familiar with TMP, this is what
> a beginner would expect for `if` intuitively, so why not just extend `if`
> to match the expectation?
>
No, this is *not* what a beginner would expect `if` to do. Beginners would
and should not expect `if` to make lines invisible to the compiler. That is
completely unlike the normal behavior of `if`.
--
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/2b888113-d4f1-4f45-85c8-3cbd62f514e4%40isocpp.org.
------=_Part_3357_2099121564.1457876517278
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, March 13, 2016 at 12:53:38 AM UTC-5, TO=
NGARI J 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"=
>On Sunday, March 13, 2016 at 3:51:50 AM UTC+8, Ville Voutilainen wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">On 12 March 2016 at 21:43, Greg Marr &=
lt;<a rel=3D"nofollow">greg...@gmail.com</a>> wrote:
<br>>> Do we really need a keyword for that? I don't see the rati=
onale explained
<br>>> anywhere in the proposal.
<br>>
<br>>
<br>> if(can_do_something())
<br>> {
<br>> =C2=A0 =C2=A0 do_something();
<br>> }
<br>> else
<br>> {
<br>> =C2=A0 =C2=A0 do_something_else();
<br>> }
<br>>
<br>> If optimization is enabled, the compiler MAY attempt to see if
<br>> can_do_something() produces a constant, and if so may eliminate on=
e branch
<br>> or the other. =C2=A0If it can't, it outputs the test and both =
calls, so both
<br>> calls must compile without error.
<br>
<br>
<br>Regardless of whether optimization is enabled, I know that the
<br>compiler will check the full validity
<br>of the else-branch, so it can't contain any 'nonsense', eve=
n if it's
<br>dependent 'nonsense'. Making
<br>an if do the same thing as if constexpr would lose that guarantee.
<br></blockquote><div><br></div><div>This code:</div><div style=3D"border:1=
px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250=
,250)"><code><div><span style=3D"color:#008">struct</span><span style=3D"co=
lor:#000"> A</span><span style=3D"color:#660">{};</span><span style=3D"colo=
r:#000"><br><br></span><span style=3D"color:#008">template</span><span styl=
e=3D"color:#660"><</span><span style=3D"color:#008">bool</span><span sty=
le=3D"color:#000"> flag</span><span style=3D"color:#660">></span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#008">void</span><span =
style=3D"color:#000"> f</span><span style=3D"color:#660">()</span><span sty=
le=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 A a</span><span style=3D"color:#660">;</s=
pan><span style=3D"color:#000"><br>=C2=A0 =C2=A0 a</span><span style=3D"col=
or:#660">.</span><span style=3D"color:#000">f</span><span style=3D"color:#6=
60">();</span><span style=3D"color:#000"> </span><span style=3D"color:#800"=
>// error: no member named 'f'</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br><=
/span></div></code></div><div><br></div><div>will generate error with clang=
& g++ without instantiating the template even though it's not requ=
ired by the standard.</div><div><br></div><div>Does your proposal tend to a=
llow the compiler to emit diagnostic in the example:</div><div><div style=
=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color=
:rgb(250,250,250)"><code><div><span style=3D"color:#008">template</span><sp=
an style=3D"color:#660"><</span><span style=3D"color:#008">bool</span><s=
pan style=3D"color:#000"> flag</span><span style=3D"color:#660">></span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#008">void</span=
><span style=3D"color:#000"> f</span><span style=3D"color:#660">()</span><s=
pan style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><spa=
n style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">=
if</span><span style=3D"color:#000"> </span><span style=3D"color:#008">cons=
texpr</span><span style=3D"color:#000"> </span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">flag</span><span style=3D"color:#660">)</=
span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
A a</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 a</span><span style=3D"color:#660">.</span><s=
pan style=3D"color:#000">f</span><span style=3D"color:#660">();</span><span=
style=3D"color:#000"><br>=C2=A0 =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><div>?</div></div><div><br></div><div>I'm not s=
uggesting changing `if` in non-template context, what I'd like to see i=
s allowing `if` to behave as the proposed `if constexpr` when it's in t=
emplate and the condition is a dependent-expression. This way, you still ge=
t the traditional `if` guarantee in normal case, and you get the desired la=
zy-evaluation in generic case, and the diagnostic in the above example is s=
till allowed.</div></div></blockquote><div><br>See, the problem is that the=
expression doesn't just have to be a "dependent-expression".=
It must be a dependent expression which can be evaluated at compile time. =
A function call can be a dependent-expression, but unless that function is =
`constexpr`, the compiler can't do anything with it.<br><br>That's =
why it's a good idea to put `constexpr` in the condition. It tells the =
user what they have to do in order to make the code work, and it tells the =
user that they will get special behavior by doing so.<br>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Rem=
ember the early day when we're not yet familiar with TMP, this is what =
a beginner would expect for `if` intuitively, so why not just extend `if` t=
o match the expectation?</div></div></blockquote><div><br>No, this is <i>no=
t</i> what a beginner would expect `if` to do. Beginners would and should n=
ot expect `if` to make lines invisible to the compiler. That is completely =
unlike the normal behavior of `if`. <br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2b888113-d4f1-4f45-85c8-3cbd62f514e4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2b888113-d4f1-4f45-85c8-3cbd62f514e4=
%40isocpp.org</a>.<br />
------=_Part_3357_2099121564.1457876517278--
------=_Part_3356_1309773436.1457876517277--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 13 Mar 2016 06:47:56 -0700 (PDT)
Raw View
------=_Part_138_1939460290.1457876876799
Content-Type: multipart/alternative;
boundary="----=_Part_139_221854257.1457876876800"
------=_Part_139_221854257.1457876876800
Content-Type: text/plain; charset=UTF-8
On Sunday, March 13, 2016 at 9:41:57 AM UTC-4, Nicol Bolas wrote:
>
>
>
> On Sunday, March 13, 2016 at 12:53:38 AM UTC-5, TONGARI J wrote:
>>
>> On Sunday, March 13, 2016 at 3:51:50 AM UTC+8, Ville Voutilainen wrote:
>>>
>>> On 12 March 2016 at 21:43, Greg Marr <greg...@gmail.com> wrote:
>>> >> Do we really need a keyword for that? I don't see the rationale
>>> explained
>>> >> anywhere in the proposal.
>>> >
>>> >
>>> > if(can_do_something())
>>> > {
>>> > do_something();
>>> > }
>>> > else
>>> > {
>>> > do_something_else();
>>> > }
>>> >
>>> > If optimization is enabled, the compiler MAY attempt to see if
>>> > can_do_something() produces a constant, and if so may eliminate one
>>> branch
>>> > or the other. If it can't, it outputs the test and both calls, so
>>> both
>>> > calls must compile without error.
>>>
>>>
>>> Regardless of whether optimization is enabled, I know that the
>>> compiler will check the full validity
>>> of the else-branch, so it can't contain any 'nonsense', even if it's
>>> dependent 'nonsense'. Making
>>> an if do the same thing as if constexpr would lose that guarantee.
>>>
>>
>> This code:
>> struct A{};
>>
>> template<bool flag>
>> void f()
>> {
>> A a;
>> a.f(); // error: no member named 'f'
>> }
>>
>> will generate error with clang & g++ without instantiating the template
>> even though it's not required by the standard.
>>
>> Does your proposal tend to allow the compiler to emit diagnostic in the
>> example:
>> template<bool flag>
>> void f()
>> {
>> if constexpr (flag)
>> {
>> A a;
>> a.f();
>> }
>> }
>> ?
>>
>> I'm not suggesting changing `if` in non-template context, what I'd like
>> to see is allowing `if` to behave as the proposed `if constexpr` when it's
>> in template and the condition is a dependent-expression. This way, you
>> still get the traditional `if` guarantee in normal case, and you get the
>> desired lazy-evaluation in generic case, and the diagnostic in the above
>> example is still allowed.
>>
>
> See, the problem is that the expression doesn't just have to be a
> "dependent-expression". It must be a dependent expression which can be
> evaluated at compile time. A function call can be a dependent-expression,
> but unless that function is `constexpr`, the compiler can't do anything
> with it.
>
> That's why it's a good idea to put `constexpr` in the condition. It tells
> the user what they have to do in order to make the code work, and it tells
> the user that they will get special behavior by doing so.
>
There's also another issue. `constexpr` functions don't have to be able to
be called at compile time for every set of parameters. So just because the
"dependent-expression" is labeled `constexpr` doesn't mean it actually is.
And since it would not be an error to put a non-`constexpr` expression in
an `if` clause, the user doesn't get a proper error message for doing this.
It's much better for the user to be explicit and up-front about what they
want to have happen. If you see `if constexpr` in code, then you *know*
that the user is writing code that will be conditionally instantiated. You
don't have to guess whether that's what is going on based on whether the
expression appears `constexpr` or not.
--
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/536c12ab-5783-46b8-aeaa-ce952765727f%40isocpp.org.
------=_Part_139_221854257.1457876876800
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, March 13, 2016 at 9:41:57 AM UTC-4, Nicol Bolas=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><b=
r>On Sunday, March 13, 2016 at 12:53:38 AM UTC-5, TONGARI J wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, March 13, 2016 a=
t 3:51:50 AM UTC+8, Ville Voutilainen wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">On 12 March 2016 at 21:43, Greg Marr <<a rel=3D"nofollow">greg.=
...@gmail.com</a>> wrote:
<br>>> Do we really need a keyword for that? I don't see the rati=
onale explained
<br>>> anywhere in the proposal.
<br>>
<br>>
<br>> if(can_do_something())
<br>> {
<br>> =C2=A0 =C2=A0 do_something();
<br>> }
<br>> else
<br>> {
<br>> =C2=A0 =C2=A0 do_something_else();
<br>> }
<br>>
<br>> If optimization is enabled, the compiler MAY attempt to see if
<br>> can_do_something() produces a constant, and if so may eliminate on=
e branch
<br>> or the other. =C2=A0If it can't, it outputs the test and both =
calls, so both
<br>> calls must compile without error.
<br>
<br>
<br>Regardless of whether optimization is enabled, I know that the
<br>compiler will check the full validity
<br>of the else-branch, so it can't contain any 'nonsense', eve=
n if it's
<br>dependent 'nonsense'. Making
<br>an if do the same thing as if constexpr would lose that guarantee.
<br></blockquote><div><br></div><div>This code:</div><div style=3D"border:1=
px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250=
,250)"><code><div><span style=3D"color:#008">struct</span><span style=3D"co=
lor:#000"> A</span><span style=3D"color:#660">{};</span><span style=3D"colo=
r:#000"><br><br></span><span style=3D"color:#008">template</span><span styl=
e=3D"color:#660"><</span><span style=3D"color:#008">bool</span><span sty=
le=3D"color:#000"> flag</span><span style=3D"color:#660">></span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#008">void</span><span =
style=3D"color:#000"> f</span><span style=3D"color:#660">()</span><span sty=
le=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 A a</span><span style=3D"color:#660">;</s=
pan><span style=3D"color:#000"><br>=C2=A0 =C2=A0 a</span><span style=3D"col=
or:#660">.</span><span style=3D"color:#000">f</span><span style=3D"color:#6=
60">();</span><span style=3D"color:#000"> </span><span style=3D"color:#800"=
>// error: no member named 'f'</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br><=
/span></div></code></div><div><br></div><div>will generate error with clang=
& g++ without instantiating the template even though it's not requ=
ired by the standard.</div><div><br></div><div>Does your proposal tend to a=
llow the compiler to emit diagnostic in the example:</div><div><div style=
=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color=
:rgb(250,250,250)"><code><div><span style=3D"color:#008">template</span><sp=
an style=3D"color:#660"><</span><span style=3D"color:#008">bool</span><s=
pan style=3D"color:#000"> flag</span><span style=3D"color:#660">></span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#008">void</span=
><span style=3D"color:#000"> f</span><span style=3D"color:#660">()</span><s=
pan style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><spa=
n style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">=
if</span><span style=3D"color:#000"> </span><span style=3D"color:#008">cons=
texpr</span><span style=3D"color:#000"> </span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">flag</span><span style=3D"color:#660">)</=
span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
A a</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 a</span><span style=3D"color:#660">.</span><s=
pan style=3D"color:#000">f</span><span style=3D"color:#660">();</span><span=
style=3D"color:#000"><br>=C2=A0 =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><div>?</div></div><div><br></div><div>I'm not s=
uggesting changing `if` in non-template context, what I'd like to see i=
s allowing `if` to behave as the proposed `if constexpr` when it's in t=
emplate and the condition is a dependent-expression. This way, you still ge=
t the traditional `if` guarantee in normal case, and you get the desired la=
zy-evaluation in generic case, and the diagnostic in the above example is s=
till allowed.</div></div></blockquote><div><br>See, the problem is that the=
expression doesn't just have to be a "dependent-expression".=
It must be a dependent expression which can be evaluated at compile time. =
A function call can be a dependent-expression, but unless that function is =
`constexpr`, the compiler can't do anything with it.<br><br>That's =
why it's a good idea to put `constexpr` in the condition. It tells the =
user what they have to do in order to make the code work, and it tells the =
user that they will get special behavior by doing so.<br></div></div></bloc=
kquote><div><br>There's also another issue. `constexpr` functions don&#=
39;t have to be able to be called at compile time for every set of paramete=
rs. So just because the "dependent-expression" is labeled `conste=
xpr` doesn't mean it actually is. And since it would not be an error to=
put a non-`constexpr` expression in an `if` clause, the user doesn't g=
et a proper error message for doing this.<br><br>It's much better for t=
he user to be explicit and up-front about what they want to have happen. If=
you see `if constexpr` in code, then you <i>know</i> that the user is writ=
ing code that will be conditionally instantiated. You don't have to gue=
ss whether that's what is going on based on whether the expression appe=
ars `constexpr` or not.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/536c12ab-5783-46b8-aeaa-ce952765727f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/536c12ab-5783-46b8-aeaa-ce952765727f=
%40isocpp.org</a>.<br />
------=_Part_139_221854257.1457876876800--
------=_Part_138_1939460290.1457876876799--
.