Topic: if-constexpr short circuiting ambiguity?
Author: lefticus@gmail.com
Date: Tue, 28 Jun 2016 21:33:28 -0700 (PDT)
Raw View
------=_Part_1209_85361982.1467174808246
Content-Type: multipart/alternative;
boundary="----=_Part_1210_1150458972.1467174808247"
------=_Part_1210_1150458972.1467174808247
Content-Type: text/plain; charset=UTF-8
Forgive me if this has already been answered or I'm posting to the wrong
forum.
I was just reading the if-constexpr proposal that was accepted in Oulu
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0292r1.html, I
believe) and trying out the implementation that's currently on clang's
trunk. I believe there is an unresolved question about short circuiting.
Example:
#include <iostream>
#include <type_traits>
struct MyType
{
static const int i = 5;
};
template<typename T>
void do_thing(const T &t)
{
if constexpr (std::is_same_v<MyType, T> && T::i == 5) {
std::cout << "MyType::i == 5\n";
} else {
std::cout << "don't know...\n";
}
}
int main()
{
do_thing(MyType());
do_thing(3); // fails to compile because of the T::i expression in the
if-constexpr above
}
This code fails to compile in the current implementation of if-constexpr in
clang.
However, the equivalent code:
#include <type_traits>
struct MyType
{
static const int i = 5;
};
template<typename T>
auto do_thing(const T &t) -> std::enable_if_t<std::is_same<MyType, T>::value
&& T::i == 5>
{
}
template<typename T>
auto do_thing(const T &t) -> std::enable_if_t<!std::is_same<MyType, T>::
value>
{
}
int main()
{
do_thing(MyType());
do_thing(3);
}
Succeeds to compile.
It would be my opinion that the if-constexpr conditional *should*
short-circuit at compile time, but I don't see if the accepted proposal
specifies one way or the other.
Thank you,
Jason
--
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/d2934cdf-6a6e-47c7-aa04-660847a8167b%40isocpp.org.
------=_Part_1210_1150458972.1467174808247
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Forgive me if this has already been answered or I'=
;m posting to the wrong forum.</div><div><br></div>I was just reading the i=
f-constexpr proposal that was accepted in Oulu (http://www.open-std.org/jtc=
1/sc22/wg21/docs/papers/2016/p0292r1.html, I believe) and trying out the im=
plementation that's currently on clang's trunk. I believe there is =
an unresolved question about short circuiting.<div><br></div><div>Example:<=
/div><div><br></div><div class=3D"prettyprint" style=3D"border: 1px solid r=
gb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 2=
50);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span class=
=3D"styled-by-prettify"><div class=3D"subprettyprint"><font color=3D"#00000=
0">#include <iostream></font></div><div class=3D"subprettyprint"><fon=
t color=3D"#000000">#include <type_traits></font></div><div class=3D"=
subprettyprint"><br></div><div class=3D"subprettyprint"><font color=3D"#000=
000">struct MyType</font></div><div class=3D"subprettyprint"><font color=3D=
"#000000">{</font></div><div class=3D"subprettyprint"><font color=3D"#00000=
0">=C2=A0 static const int i =3D 5;</font></div><div class=3D"subprettyprin=
t"><font color=3D"#000000">};</font></div><div class=3D"subprettyprint"><fo=
nt color=3D"#000000"><br></font></div><div class=3D"subprettyprint"><font c=
olor=3D"#000000">template<typename T></font></div><div class=3D"subpr=
ettyprint"><font color=3D"#000000">void do_thing(const T &t)</font></di=
v><div class=3D"subprettyprint"><font color=3D"#000000">{</font></div><div =
class=3D"subprettyprint"><font color=3D"#000000">=C2=A0 if constexpr (std::=
is_same_v<MyType, T> && T::i =3D=3D 5) {</font></div><div cla=
ss=3D"subprettyprint"><font color=3D"#000000">=C2=A0 =C2=A0 std::cout <&=
lt; "MyType::i =3D=3D 5\n";</font></div><div class=3D"subprettypr=
int"><font color=3D"#000000">=C2=A0 } else {</font></div><div class=3D"subp=
rettyprint"><font color=3D"#000000">=C2=A0 =C2=A0 std::cout << "=
don't know...\n";</font></div><div class=3D"subprettyprint"><font =
color=3D"#000000">=C2=A0 }</font></div><div class=3D"subprettyprint"><font =
color=3D"#000000">}</font></div><div class=3D"subprettyprint"><font color=
=3D"#000000"><br></font></div><div class=3D"subprettyprint"><font color=3D"=
#000000">int main()</font></div><div class=3D"subprettyprint"><font color=
=3D"#000000">{</font></div><div class=3D"subprettyprint"><font color=3D"#00=
0000">=C2=A0 do_thing(MyType());</font></div><div class=3D"subprettyprint">=
<font color=3D"#000000">=C2=A0 do_thing(3); // fails to compile because of =
the T::i expression in the if-constexpr above</font></div><div class=3D"sub=
prettyprint"><font color=3D"#000000">}</font></div></span></div></code></di=
v><div><br></div><div><br></div><div>This code fails to compile in the curr=
ent implementation of if-constexpr in clang.</div><div><br></div><div>Howev=
er, the equivalent code:</div><div><br></div><div class=3D"prettyprint" sty=
le=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgrou=
nd-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #800;" class=3D"styled-by-prettify">#in=
clude</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #080;" class=3D"styled-by-prettify"><type_trait=
s></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">str=
uct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">MyType</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><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">static</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> i </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">5</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></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> do=
_thing</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> T </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">t</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">-></span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>enable_if_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">is_same</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">MyType</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">>::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">value </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&&</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">5</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-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 style=3D"color: #008;" class=3D"styled-by-prett=
ify">typename</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">><=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> do_thing</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> T </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">&</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">t</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">-></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">enable_if_t</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify"><!</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">is_same</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">MyType</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">>::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">value</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 do_thing</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">MyType</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 do_thing</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><div><=
br><br></div><div>Succeeds to compile.</div><div><br></div><div>It would be=
my opinion that the if-constexpr conditional *should* short-circuit at com=
pile time, but I don't see if the accepted proposal specifies one way o=
r the other.</div><div><br></div><div>Thank you,</div><div>Jason</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/d2934cdf-6a6e-47c7-aa04-660847a8167b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d2934cdf-6a6e-47c7-aa04-660847a8167b=
%40isocpp.org</a>.<br />
------=_Part_1210_1150458972.1467174808247--
------=_Part_1209_85361982.1467174808246--
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Wed, 29 Jun 2016 07:41:56 +0200
Raw View
The condition for the if-constexpr is instantiated as a whole,
and needs to be valid. You can nest the if-constexpr, though:
if constexpr (std::is_same_v<MyType, T>)
if constexpr (T::i =3D=3D 5) // not instantiated if outer condition is =
false
...
Jens
On 06/29/2016 06:33 AM, lefticus@gmail.com wrote:
> Forgive me if this has already been answered or I'm posting to the wrong =
forum.
>=20
> I was just reading the if-constexpr proposal that was accepted in Oulu (h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0292r1.html, I beli=
eve) and trying out the implementation that's currently on clang's trunk. I=
believe there is an unresolved question about short circuiting.
>=20
> Example:
>=20
> ||
> #include <iostream>
> #include <type_traits>
>=20
> struct MyType
> {
> static const int i =3D 5;
> };
>=20
> template<typename T>
> void do_thing(const T &t)
> {
> if constexpr (std::is_same_v<MyType, T> && T::i =3D=3D 5) {
> std::cout << "MyType::i =3D=3D 5\n";
> } else {
> std::cout << "don't know...\n";
> }
> }
>=20
> int main()
> {
> do_thing(MyType());
> do_thing(3); // fails to compile because of the T::i expression in the =
if-constexpr above
> }
>=20
>=20
> This code fails to compile in the current implementation of if-constexpr =
in clang.
>=20
> However, the equivalent code:
>=20
> ||
> #include<type_traits>
>=20
>=20
> structMyType
> {
> staticconstinti =3D5;
> };
>=20
> template<typenameT>
> autodo_thing(constT &t)->std::enable_if_t<std::is_same<MyType,T>::value=
&&T::i =3D=3D5>
> {
> }
>=20
> template<typenameT>
> autodo_thing(constT &t)->std::enable_if_t<!std::is_same<MyType,T>::valu=
e>
> {
> }
>=20
> intmain()
> {
> do_thing(MyType());
> do_thing(3);
> }
>=20
>=20
> Succeeds to compile.
>=20
> It would be my opinion that the if-constexpr conditional *should* short-c=
ircuit at compile time, but I don't see if the accepted proposal specifies =
one way or the other.
>=20
> Thank you,
> Jason
>=20
> --=20
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/d2934cdf-6a6e-47c7-aa04-660847a8167b%40isocpp.=
org <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d2934cdf-=
6a6e-47c7-aa04-660847a8167b%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/57735FA4.8040302%40gmx.net.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 29 Jun 2016 00:46:20 -0500
Raw View
On Tue, Jun 28, 2016 at 11:33 PM, <lefticus@gmail.com> wrote:
>
>
> Succeeds to compile.
>
> It would be my opinion that the if-constexpr conditional *should*
> short-circuit at compile time, but I don't see if the accepted proposal
> specifies one way or the other.
It compiles not because of short-circuit but sfinae in
general; it still works if you swap the sub-expressions
around &&. If that is the behavior you expect we
need to say that substitution failures give false values.
However, I'm skeptical about its generality.
The constexpr if example you gave is truly equiv to
the following:
#include <type_traits>
struct MyType
{
static const int i = 5;
};
template<typename T>
auto do_thing(const T &t, std::true_type)
{
}
template<typename T>
auto do_thing(const T &t, std::false_type)
{
}
template<typename T>
auto do_thing(const T &t)
{
return do_thing(t, std::bool_constant<std::is_same_v<MyType, T> &&
T::i == 5>());
}
int main()
{
do_thing(MyType());
do_thing(3);
}
, which doesn't work in the same way.
OK, Jens answered it... And it's way better than
what I'm going to suggest, which is based on
constexpr lambda expression sfinae...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuCsEgOy0rrpqynGMS5fLNU8egHq8q6k9H344AytrOrJpA%40mail.gmail.com.
.
Author: lefticus@gmail.com
Date: Wed, 29 Jun 2016 05:19:41 -0700 (PDT)
Raw View
------=_Part_2733_1652475891.1467202781809
Content-Type: multipart/alternative;
boundary="----=_Part_2734_1185356197.1467202781817"
------=_Part_2734_1185356197.1467202781817
Content-Type: text/plain; charset=UTF-8
These are the replies I expected to see.
Should the language of the constexpr-if documentation needs to be updated
to say that the entire condition must be well-formed / it is compiled as a
whole? I did not see that explicitly stated in the proposal.
-Jason
On Tuesday, June 28, 2016 at 11:46:22 PM UTC-6, Zhihao Yuan wrote:
>
> On Tue, Jun 28, 2016 at 11:33 PM, <left...@gmail.com <javascript:>>
> wrote:
> >
> >
> > Succeeds to compile.
> >
> > It would be my opinion that the if-constexpr conditional *should*
> > short-circuit at compile time, but I don't see if the accepted proposal
> > specifies one way or the other.
>
> It compiles not because of short-circuit but sfinae in
> general; it still works if you swap the sub-expressions
> around &&. If that is the behavior you expect we
> need to say that substitution failures give false values.
> However, I'm skeptical about its generality.
>
> The constexpr if example you gave is truly equiv to
> the following:
>
> #include <type_traits>
>
> struct MyType
> {
> static const int i = 5;
> };
>
> template<typename T>
> auto do_thing(const T &t, std::true_type)
> {
> }
>
> template<typename T>
> auto do_thing(const T &t, std::false_type)
> {
> }
>
> template<typename T>
> auto do_thing(const T &t)
> {
> return do_thing(t, std::bool_constant<std::is_same_v<MyType, T> &&
> T::i == 5>());
> }
>
> int main()
> {
> do_thing(MyType());
> do_thing(3);
> }
>
> , which doesn't work in the same way.
>
> OK, Jens answered it... And it's way better than
> what I'm going to suggest, which is based on
> constexpr lambda expression sfinae...
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://blog.miator.net/
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%40isocpp.org.
------=_Part_2734_1185356197.1467202781817
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">These are the replies I expected to see.=C2=A0<div><br></d=
iv><div>Should the language of the constexpr-if documentation needs to be u=
pdated to say that the entire condition must be well-formed / it is compile=
d as a whole? I did not see that explicitly stated in the proposal.</div><d=
iv><br></div><div>-Jason</div><div><br><br>On Tuesday, June 28, 2016 at 11:=
46:22 PM UTC-6, Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">On Tue, Jun 28, 2016 at 11:33 PM, =C2=A0<<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"21AvwKCRBgAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"thi=
s.href=3D'javascript:';return true;">left...@gmail.com</a>> wrot=
e:
<br>>
<br>>
<br>> Succeeds to compile.
<br>>
<br>> It would be my opinion that the if-constexpr conditional *should*
<br>> short-circuit at compile time, but I don't see if the accepted=
proposal
<br>> specifies one way or the other.
<br>
<br>It compiles not because of short-circuit but sfinae in
<br>general; it still works if you swap the sub-expressions
<br>around &&. =C2=A0If that is the behavior you expect we
<br>need to say that substitution failures give false values.
<br>However, I'm skeptical about its generality.
<br>
<br>The constexpr if example you gave is truly equiv to
<br>the following:
<br>
<br>#include <type_traits>
<br>
<br>struct MyType
<br>{
<br>=C2=A0 static const int i =3D 5;
<br>};
<br>
<br>template<typename T>
<br>=C2=A0 auto do_thing(const T &t, std::true_type)
<br>{
<br>}
<br>
<br>template<typename T>
<br>=C2=A0 auto do_thing(const T &t, std::false_type)
<br>{
<br>}
<br>
<br>template<typename T>
<br>=C2=A0 auto do_thing(const T &t)
<br>{
<br>=C2=A0 =C2=A0 return do_thing(t, std::bool_constant<std::is_<wbr>sam=
e_v<MyType, T> &&
<br>T::i =3D=3D 5>());
<br>}
<br>
<br>int main()
<br>{
<br>=C2=A0 do_thing(MyType());
<br>=C2=A0 do_thing(3);
<br>}
<br>
<br>, which doesn't work in the same way.
<br>
<br>OK, Jens answered it... And it's way better than
<br>what I'm going to suggest, which is based on
<br>constexpr lambda expression sfinae...
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://blog.miator.net/" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp=
%3A%2F%2Fblog.miator.net%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHmWTsHV=
Z1D7s1tahvZikRjgaSh7g';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fblog.miator.net%2F\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNHmWTsHVZ1D7s1tahvZikRjgaSh7g';return true;">http:=
//blog.miator.net/</a>
<br></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8=
%40isocpp.org</a>.<br />
------=_Part_2734_1185356197.1467202781817--
------=_Part_2733_1652475891.1467202781809--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Wed, 29 Jun 2016 08:28:39 -0400
Raw View
--94eb2c07b1d8b99323053669e45d
Content-Type: text/plain; charset=UTF-8
Hi Jason!
If you think this is the direction it should go. how about a proposal that
explores the pros and cons of it? It might be interesting, and it would
seem intuitive at first glance, but the devil's in the details so such a
proposal would definitely be useful.
Cheers!
2016-06-29 8:19 GMT-04:00 <lefticus@gmail.com>:
> These are the replies I expected to see.
>
> Should the language of the constexpr-if documentation needs to be updated
> to say that the entire condition must be well-formed / it is compiled as a
> whole? I did not see that explicitly stated in the proposal.
>
> -Jason
>
>
> On Tuesday, June 28, 2016 at 11:46:22 PM UTC-6, Zhihao Yuan wrote:
>
>> On Tue, Jun 28, 2016 at 11:33 PM, <left...@gmail.com> wrote:
>> >
>> >
>> > Succeeds to compile.
>> >
>> > It would be my opinion that the if-constexpr conditional *should*
>> > short-circuit at compile time, but I don't see if the accepted proposal
>> > specifies one way or the other.
>>
>> It compiles not because of short-circuit but sfinae in
>> general; it still works if you swap the sub-expressions
>> around &&. If that is the behavior you expect we
>> need to say that substitution failures give false values.
>> However, I'm skeptical about its generality.
>>
>> The constexpr if example you gave is truly equiv to
>> the following:
>>
>> #include <type_traits>
>>
>> struct MyType
>> {
>> static const int i = 5;
>> };
>>
>> template<typename T>
>> auto do_thing(const T &t, std::true_type)
>> {
>> }
>>
>> template<typename T>
>> auto do_thing(const T &t, std::false_type)
>> {
>> }
>>
>> template<typename T>
>> auto do_thing(const T &t)
>> {
>> return do_thing(t, std::bool_constant<std::is_same_v<MyType, T> &&
>> T::i == 5>());
>> }
>>
>> int main()
>> {
>> do_thing(MyType());
>> do_thing(3);
>> }
>>
>> , which doesn't work in the same way.
>>
>> OK, Jens answered it... And it's way better than
>> what I'm going to suggest, which is based on
>> constexpr lambda expression sfinae...
>>
>> --
>> Zhihao Yuan, ID lichray
>> The best way to predict the future is to invent it.
>> ___________________________________________________
>> 4BSD -- http://blog.miator.net/
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%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/CAKiZDp2nGyj5e5BDNWjyv%2BYsURqhDC7owmoAiXvhYwLJa4YoZg%40mail.gmail.com.
--94eb2c07b1d8b99323053669e45d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Hi Jason!<br><br></div>If you think this is the =
direction it should go. how about a proposal that explores the pros and con=
s of it? It might be interesting, and it would seem intuitive at first glan=
ce, but the devil's in the details so such a proposal would definitely =
be useful.<br><br></div>Cheers!<br></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">2016-06-29 8:19 GMT-04:00 <span dir=3D"ltr"><<a=
href=3D"mailto:lefticus@gmail.com" target=3D"_blank">lefticus@gmail.com</a=
>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">These are =
the replies I expected to see.=C2=A0<div><br></div><div>Should the language=
of the constexpr-if documentation needs to be updated to say that the enti=
re condition must be well-formed / it is compiled as a whole? I did not see=
that explicitly stated in the proposal.</div><div><br></div><div>-Jason</d=
iv><div><br><br>On Tuesday, June 28, 2016 at 11:46:22 PM UTC-6, Zhihao Yuan=
wrote:<div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Tu=
e, Jun 28, 2016 at 11:33 PM, =C2=A0<<a rel=3D"nofollow">left...@gmail.co=
m</a>> wrote:
<br>>
<br>>
<br>> Succeeds to compile.
<br>>
<br>> It would be my opinion that the if-constexpr conditional *should*
<br>> short-circuit at compile time, but I don't see if the accepted=
proposal
<br>> specifies one way or the other.
<br>
<br>It compiles not because of short-circuit but sfinae in
<br>general; it still works if you swap the sub-expressions
<br>around &&.=C2=A0 If that is the behavior you expect we
<br>need to say that substitution failures give false values.
<br>However, I'm skeptical about its generality.
<br>
<br>The constexpr if example you gave is truly equiv to
<br>the following:
<br>
<br>#include <type_traits>
<br>
<br>struct MyType
<br>{
<br>=C2=A0 static const int i =3D 5;
<br>};
<br>
<br>template<typename T>
<br>=C2=A0 auto do_thing(const T &t, std::true_type)
<br>{
<br>}
<br>
<br>template<typename T>
<br>=C2=A0 auto do_thing(const T &t, std::false_type)
<br>{
<br>}
<br>
<br>template<typename T>
<br>=C2=A0 auto do_thing(const T &t)
<br>{
<br>=C2=A0 =C2=A0 return do_thing(t, std::bool_constant<std::is_same_v&l=
t;MyType, T> &&
<br>T::i =3D=3D 5>());
<br>}
<br>
<br>int main()
<br>{
<br>=C2=A0 do_thing(MyType());
<br>=C2=A0 do_thing(3);
<br>}
<br>
<br>, which doesn't work in the same way.
<br>
<br>OK, Jens answered it... And it's way better than
<br>what I'm going to suggest, which is based on
<br>constexpr lambda expression sfinae...
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>___________________________________________________
<br>4BSD -- <a href=3D"http://blog.miator.net/" rel=3D"nofollow" target=3D"=
_blank">http://blog.miator.net/</a>
<br></blockquote></div></div></div></div><div><div class=3D"h5">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-=
4400-8dfa-b692cdf7cfb8%40isocpp.org</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">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/CAKiZDp2nGyj5e5BDNWjyv%2BYsURqhDC7owm=
oAiXvhYwLJa4YoZg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2nGyj5e5=
BDNWjyv%2BYsURqhDC7owmoAiXvhYwLJa4YoZg%40mail.gmail.com</a>.<br />
--94eb2c07b1d8b99323053669e45d--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 29 Jun 2016 11:10:46 -0700
Raw View
--001a11401f2035792005366eac14
Content-Type: text/plain; charset=UTF-8
On Wed, Jun 29, 2016 at 5:19 AM, <lefticus@gmail.com> wrote:
> These are the replies I expected to see.
>
> Should the language of the constexpr-if documentation needs to be updated
> to say that the entire condition must be well-formed / it is compiled as a
> whole? I did not see that explicitly stated in the proposal.
>
What documentation are you referring to?
The standard is a specification, not a tutorial, and it specifies what it
needs to in this case. The specified behavior for instantiation of a
function template is that the entire function body is instantiated;
constexpr if explicitly opts out its unchosen controlled statement from
this, but says nothing about its condition, so the normal rules apply there.
It's really up to the paper author to decide what details they cover in
their paper, but the primary purpose of those papers is as input to the
committee process rather than communication with the rest of the world, and
in the committee discussion we did talk about this case.
On the other hand, I would certainly expect this to be something that
someone teaching this feature would mention.
-Jason
>
>
> On Tuesday, June 28, 2016 at 11:46:22 PM UTC-6, Zhihao Yuan wrote:
>
>> On Tue, Jun 28, 2016 at 11:33 PM, <left...@gmail.com> wrote:
>> >
>> >
>> > Succeeds to compile.
>> >
>> > It would be my opinion that the if-constexpr conditional *should*
>> > short-circuit at compile time, but I don't see if the accepted proposal
>> > specifies one way or the other.
>>
>> It compiles not because of short-circuit but sfinae in
>> general; it still works if you swap the sub-expressions
>> around &&. If that is the behavior you expect we
>> need to say that substitution failures give false values.
>> However, I'm skeptical about its generality.
>>
>> The constexpr if example you gave is truly equiv to
>> the following:
>>
>> #include <type_traits>
>>
>> struct MyType
>> {
>> static const int i = 5;
>> };
>>
>> template<typename T>
>> auto do_thing(const T &t, std::true_type)
>> {
>> }
>>
>> template<typename T>
>> auto do_thing(const T &t, std::false_type)
>> {
>> }
>>
>> template<typename T>
>> auto do_thing(const T &t)
>> {
>> return do_thing(t, std::bool_constant<std::is_same_v<MyType, T> &&
>> T::i == 5>());
>> }
>>
>> int main()
>> {
>> do_thing(MyType());
>> do_thing(3);
>> }
>>
>> , which doesn't work in the same way.
>>
>> OK, Jens answered it... And it's way better than
>> what I'm going to suggest, which is based on
>> constexpr lambda expression sfinae...
>>
>> --
>> Zhihao Yuan, ID lichray
>> The best way to predict the future is to invent it.
>> ___________________________________________________
>> 4BSD -- http://blog.miator.net/
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%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/CAOfiQq%3Dg7%2BQcVkFyDej7ovgkgyg7PSXaE77rx5ZB8Z6QPCX_Wg%40mail.gmail.com.
--001a11401f2035792005366eac14
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jun 29, 2016 at 5:19 AM, <span dir=3D"ltr"><<a href=3D"mailto:lefti=
cus@gmail.com" target=3D"_blank">lefticus@gmail.com</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">These are the replies I e=
xpected to see.=C2=A0<div><br></div><div>Should the language of the constex=
pr-if documentation needs to be updated to say that the entire condition mu=
st be well-formed / it is compiled as a whole? I did not see that explicitl=
y stated in the proposal.</div></div></blockquote><div><br></div><div>What =
documentation are you referring to?</div><div><br></div><div>The standard i=
s a specification, not a tutorial, and it specifies what it needs to in thi=
s case. The specified behavior for instantiation of a function template is =
that the entire function body is instantiated; constexpr if explicitly opts=
out its unchosen controlled statement from this, but says nothing about it=
s condition, so the normal rules apply there.</div><div><br></div><div>It&#=
39;s really up to the paper author to decide what details they cover in the=
ir paper, but the primary purpose of those papers is as input to the commit=
tee process rather than communication with the rest of the world, and in th=
e committee discussion we did talk about this case.</div><div><br></div><di=
v>On the other hand, I would certainly expect this to be something that som=
eone teaching this feature would mention.</div><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>-Jason</div><div><br><br>On Tuesday=
, June 28, 2016 at 11:46:22 PM UTC-6, Zhihao Yuan wrote:<div><div class=3D"=
h5"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">On Tue, Jun 28, 2016 at 11:33 P=
M, =C2=A0<<a rel=3D"nofollow">left...@gmail.com</a>> wrote:
<br>>
<br>>
<br>> Succeeds to compile.
<br>>
<br>> It would be my opinion that the if-constexpr conditional *should*
<br>> short-circuit at compile time, but I don't see if the accepted=
proposal
<br>> specifies one way or the other.
<br>
<br>It compiles not because of short-circuit but sfinae in
<br>general; it still works if you swap the sub-expressions
<br>around &&.=C2=A0 If that is the behavior you expect we
<br>need to say that substitution failures give false values.
<br>However, I'm skeptical about its generality.
<br>
<br>The constexpr if example you gave is truly equiv to
<br>the following:
<br>
<br>#include <type_traits>
<br>
<br>struct MyType
<br>{
<br>=C2=A0 static const int i =3D 5;
<br>};
<br>
<br>template<typename T>
<br>=C2=A0 auto do_thing(const T &t, std::true_type)
<br>{
<br>}
<br>
<br>template<typename T>
<br>=C2=A0 auto do_thing(const T &t, std::false_type)
<br>{
<br>}
<br>
<br>template<typename T>
<br>=C2=A0 auto do_thing(const T &t)
<br>{
<br>=C2=A0 =C2=A0 return do_thing(t, std::bool_constant<std::is_same_v&l=
t;MyType, T> &&
<br>T::i =3D=3D 5>());
<br>}
<br>
<br>int main()
<br>{
<br>=C2=A0 do_thing(MyType());
<br>=C2=A0 do_thing(3);
<br>}
<br>
<br>, which doesn't work in the same way.
<br>
<br>OK, Jens answered it... And it's way better than
<br>what I'm going to suggest, which is based on
<br>constexpr lambda expression sfinae...
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>___________________________________________________
<br>4BSD -- <a href=3D"http://blog.miator.net/" rel=3D"nofollow" target=3D"=
_blank">http://blog.miator.net/</a>
<br></blockquote></div></div></div></div><div><div class=3D"h5">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-=
4400-8dfa-b692cdf7cfb8%40isocpp.org</a>.<br>
</blockquote></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/CAOfiQq%3Dg7%2BQcVkFyDej7ovgkgyg7PSXa=
E77rx5ZB8Z6QPCX_Wg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3Dg7%=
2BQcVkFyDej7ovgkgyg7PSXaE77rx5ZB8Z6QPCX_Wg%40mail.gmail.com</a>.<br />
--001a11401f2035792005366eac14--
.
Author: lefticus@gmail.com
Date: Wed, 29 Jun 2016 11:46:50 -0700 (PDT)
Raw View
------=_Part_230_1461808875.1467226010548
Content-Type: multipart/alternative;
boundary="----=_Part_231_1318087624.1467226010549"
------=_Part_231_1318087624.1467226010549
Content-Type: text/plain; charset=UTF-8
I was referring to the text of the accepted proposal.
The question I've been attempting to ask is: "does the language of the
standard need to be clarified?" the answer appears to be "no."
-Jason
On Wednesday, June 29, 2016 at 12:10:49 PM UTC-6, Richard Smith wrote:
>
> On Wed, Jun 29, 2016 at 5:19 AM, <left...@gmail.com <javascript:>> wrote:
>
>> These are the replies I expected to see.
>>
>> Should the language of the constexpr-if documentation needs to be updated
>> to say that the entire condition must be well-formed / it is compiled as a
>> whole? I did not see that explicitly stated in the proposal.
>>
>
> What documentation are you referring to?
>
> The standard is a specification, not a tutorial, and it specifies what it
> needs to in this case. The specified behavior for instantiation of a
> function template is that the entire function body is instantiated;
> constexpr if explicitly opts out its unchosen controlled statement from
> this, but says nothing about its condition, so the normal rules apply there.
>
> It's really up to the paper author to decide what details they cover in
> their paper, but the primary purpose of those papers is as input to the
> committee process rather than communication with the rest of the world, and
> in the committee discussion we did talk about this case.
>
> On the other hand, I would certainly expect this to be something that
> someone teaching this feature would mention.
>
> -Jason
>>
>>
>> On Tuesday, June 28, 2016 at 11:46:22 PM UTC-6, Zhihao Yuan wrote:
>>
>>> On Tue, Jun 28, 2016 at 11:33 PM, <left...@gmail.com> wrote:
>>> >
>>> >
>>> > Succeeds to compile.
>>> >
>>> > It would be my opinion that the if-constexpr conditional *should*
>>> > short-circuit at compile time, but I don't see if the accepted
>>> proposal
>>> > specifies one way or the other.
>>>
>>> It compiles not because of short-circuit but sfinae in
>>> general; it still works if you swap the sub-expressions
>>> around &&. If that is the behavior you expect we
>>> need to say that substitution failures give false values.
>>> However, I'm skeptical about its generality.
>>>
>>> The constexpr if example you gave is truly equiv to
>>> the following:
>>>
>>> #include <type_traits>
>>>
>>> struct MyType
>>> {
>>> static const int i = 5;
>>> };
>>>
>>> template<typename T>
>>> auto do_thing(const T &t, std::true_type)
>>> {
>>> }
>>>
>>> template<typename T>
>>> auto do_thing(const T &t, std::false_type)
>>> {
>>> }
>>>
>>> template<typename T>
>>> auto do_thing(const T &t)
>>> {
>>> return do_thing(t, std::bool_constant<std::is_same_v<MyType, T> &&
>>> T::i == 5>());
>>> }
>>>
>>> int main()
>>> {
>>> do_thing(MyType());
>>> do_thing(3);
>>> }
>>>
>>> , which doesn't work in the same way.
>>>
>>> OK, Jens answered it... And it's way better than
>>> what I'm going to suggest, which is based on
>>> constexpr lambda expression sfinae...
>>>
>>> --
>>> Zhihao Yuan, ID lichray
>>> The best way to predict the future is to invent it.
>>> ___________________________________________________
>>> 4BSD -- http://blog.miator.net/
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%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/57ad28e0-9949-4e63-b98d-484f58821215%40isocpp.org.
------=_Part_231_1318087624.1467226010549
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I was referring to the text of the accepted proposal.<div>=
<br></div><div>The question I've been attempting to ask is: "does =
the language of the standard need to be clarified?" the answer appears=
to be "no."</div><div><br></div><div>-Jason<br><br>On Wednesday,=
June 29, 2016 at 12:10:49 PM UTC-6, Richard Smith wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
">On Wed, Jun 29, 2016 at 5:19 AM, <span dir=3D"ltr"><<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"7rjIjEC6BgAJ" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">left...@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">These =
are the replies I expected to see.=C2=A0<div><br></div><div>Should the lang=
uage of the constexpr-if documentation needs to be updated to say that the =
entire condition must be well-formed / it is compiled as a whole? I did not=
see that explicitly stated in the proposal.</div></div></blockquote><div><=
br></div><div>What documentation are you referring to?</div><div><br></div>=
<div>The standard is a specification, not a tutorial, and it specifies what=
it needs to in this case. The specified behavior for instantiation of a fu=
nction template is that the entire function body is instantiated; constexpr=
if explicitly opts out its unchosen controlled statement from this, but sa=
ys nothing about its condition, so the normal rules apply there.</div><div>=
<br></div><div>It's really up to the paper author to decide what detail=
s they cover in their paper, but the primary purpose of those papers is as =
input to the committee process rather than communication with the rest of t=
he world, and in the committee discussion we did talk about this case.</div=
><div><br></div><div>On the other hand, I would certainly expect this to be=
something that someone teaching this feature would mention.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>-Jason</div><div=
><br><br>On Tuesday, June 28, 2016 at 11:46:22 PM UTC-6, Zhihao Yuan wrote:=
<div><div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jun 28, 2016 at 1=
1:33 PM, =C2=A0<<a rel=3D"nofollow">left...@gmail.com</a>> wrote:
<br>>
<br>>
<br>> Succeeds to compile.
<br>>
<br>> It would be my opinion that the if-constexpr conditional *should*
<br>> short-circuit at compile time, but I don't see if the accepted=
proposal
<br>> specifies one way or the other.
<br>
<br>It compiles not because of short-circuit but sfinae in
<br>general; it still works if you swap the sub-expressions
<br>around &&.=C2=A0 If that is the behavior you expect we
<br>need to say that substitution failures give false values.
<br>However, I'm skeptical about its generality.
<br>
<br>The constexpr if example you gave is truly equiv to
<br>the following:
<br>
<br>#include <type_traits>
<br>
<br>struct MyType
<br>{
<br>=C2=A0 static const int i =3D 5;
<br>};
<br>
<br>template<typename T>
<br>=C2=A0 auto do_thing(const T &t, std::true_type)
<br>{
<br>}
<br>
<br>template<typename T>
<br>=C2=A0 auto do_thing(const T &t, std::false_type)
<br>{
<br>}
<br>
<br>template<typename T>
<br>=C2=A0 auto do_thing(const T &t)
<br>{
<br>=C2=A0 =C2=A0 return do_thing(t, std::bool_constant<std::is_<wbr>sam=
e_v<MyType, T> &&
<br>T::i =3D=3D 5>());
<br>}
<br>
<br>int main()
<br>{
<br>=C2=A0 do_thing(MyType());
<br>=C2=A0 do_thing(3);
<br>}
<br>
<br>, which doesn't work in the same way.
<br>
<br>OK, Jens answered it... And it's way better than
<br>what I'm going to suggest, which is based on
<br>constexpr lambda expression sfinae...
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://blog.miator.net/" rel=3D"nofollow" target=3D"=
_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp=
%3A%2F%2Fblog.miator.net%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHmWTsHV=
Z1D7s1tahvZikRjgaSh7g';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fblog.miator.net%2F\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNHmWTsHVZ1D7s1tahvZikRjgaSh7g';return true;">http:=
//blog.miator.net/</a>
<br></blockquote></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" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
7rjIjEC6BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"7rjIjEC6BgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/9a3f181e-acd2-4400-<wbr>8dfa-=
b692cdf7cfb8%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/57ad28e0-9949-4e63-b98d-484f58821215%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/57ad28e0-9949-4e63-b98d-484f58821215=
%40isocpp.org</a>.<br />
------=_Part_231_1318087624.1467226010549--
------=_Part_230_1461808875.1467226010548--
.