Topic: Asserting an expected compile-time failure
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 7 Oct 2013 02:06:11 -0700 (PDT)
Raw View
------=_Part_2901_26225009.1381136771698
Content-Type: text/plain; charset=ISO-8859-1
Hi All,
I wanted to share an idea about a new language feature that I have been
missing for some time.
Motivation:
One of the features offered by a statically typed language (and in fact,
probably the most important one) is a guarantee that certain declarations
or expressions will fail to compile. For instance, imagine that we had SI
units in the language:
* Length l = 1m;
*
* Duration t = 1s;
*
* t + l;* // compile time error -- a nice feature
As a library (especially a generic library) author, I would like to be able
to test if I correctly provide this safety feature guarantee. Namely, I
would like to be able to verify if certain constructs in code fail to
compile.
Proposal:
I imagine that this could be implemented by making a "branch" in the
compilation process when the code requests one. The compilation of the
"trunk" is suspended. Template instantiations and ODR usages performed from
now on, are not visible in "trunk". The compilation in the "branch"
continues until one of the two happens:
1. We get a compilation error.
2. We compiled successfully everything in the branch.
In the first case we stop compiling the "branch" and proceed to compile the
"trunk" from where we suspended. Everything is fine.
In the second case, we trigger a compile-time error in the "trunk" with a
user-provided error message.
How an additional language to support this feature would look, is depicted
in the following examples. I used an extra keyword *assert_static_failure*:
* template <typename T>
struct IsTrue;
*
* template<>
*
* struct IsTrue<true>
{
*
* constexpr static bool value = true;
** };
*
*
assert_static_failure ("test IsTrue") {
*
* IsTrue<(3 == 1)>::value;
*
} // compiles fine: no effect, no symbols ODR used or templates
instantiated
*assert_static_failure ("test IsTrue - err") {
IsTrue<(1 == 1)>::value;
*
* }* // compile-time error: a failure was asserted, but no failure occurred
another example:
*template <int N>
*
* void fun()
{
*
* static_assert (N != 0, "N must be non-zero");
*
* }
assert_static_failure ("test N == 0") {
*
* fun<0>();
*
* }* // compiles fine
*assert_static_failure ("test N != 0") {
*
* fun<1>();
*
* }* // error: expected a failure
I wanted to check in this list, if this is a feature worth standardizing,
and if it is worth pursuing with this idea.
Regards,
&rzej
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2901_26225009.1381136771698
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Hi All,<br>I wanted to share an idea about =
a new language feature that I have been missing for some time.<br><br>Motiv=
ation:<br><br>One
of the features offered by a statically typed language (and in fact,=20
probably the most important one) is a guarantee that certain=20
declarations or expressions will fail to compile. For instance, imagine tha=
t we had SI units in the language:<br><br></div><div><b> Length l =3D=
1m;<br></b></div><div><b> Duration t =3D 1s;<br></b></div><div><b>&n=
bsp; t + l;</b> // compile time error -- a nice feature<br><br></div><div>A=
s a library (especially a generic library) author, I would like to be able =
to test if I correctly provide this safety feature guarantee. Namely, I wou=
ld like to be able to verify if certain constructs in code fail to compile.=
<br><br></div><div>Proposal:<br><br></div><div>I imagine that this could be=
implemented=20
by making a "branch" in the compilation process when the code requests=20
one. The compilation of the "trunk" is suspended. Template=20
instantiations and ODR usages performed from now on, are not visible in=20
"trunk". The compilation in the "branch" continues until one of the two=20
happens:<br><br></div><div> 1. We get a compilation error.<br></div><=
div> 2. We compiled successfully everything in the branch.<br><br></d=
iv><div>In the first case we stop compiling the "branch" and proceed to com=
pile the "trunk" from where we suspended. Everything is fine.<br><br></div>=
<div>In the second case, we trigger a compile-time error in the "trunk" wit=
h a user-provided error message. <br><br></div><div>How an additional langu=
age to support this feature would look, is depicted in the following exampl=
es. I used an extra keyword <b>assert_static_failure</b>:<br></div><div><br=
><b> template <typename T><br> struct IsTrue;<br><br></b>=
</div><b> template<><br></b></div><b> struct IsTrue<tr=
ue><br> {<br></b></div><b> constexpr static bool=
value =3D true;<br></b><b> };<br></b><div><b><br> assert_stati=
c_failure ("test IsTrue") {<br></b></div><div><b> IsTrue&=
lt;(3 =3D=3D 1)>::value;<br></b></div><div> } // compiles fine: no=
effect, no symbols ODR used or templates instantiated<br><br> <b>ass=
ert_static_failure ("test IsTrue - err") {<br> IsTrue<=
(1 =3D=3D 1)>::value;<br></b></div><div><b> }</b> // compile-time =
error: a failure was asserted, but no failure occurred<br><br></div><div>an=
other example:<br></div><div><br></div><div> <b>template <int N>=
;<br></b></div><div><b> void fun()<br> {<br></b></div><div><b>&=
nbsp; static_assert (N !=3D 0, "N must be non-zero");<br></b></=
div><div><b> }<br><br> assert_static_failure ("test N =3D=3D 0"=
) {<br></b></div><div><b> fun<0>();<br></b></div><d=
iv><b> }</b> // compiles fine<br><br> <b>assert_static_failure =
("test N !=3D 0") {<br></b><div><b> fun<1>();<br></=
b></div><b> }</b> // error: expected a failure<br><br><br></div><div>=
I wanted to check in this list, if this is a feature worth standardizing, a=
nd if it is worth pursuing with this idea.<br><br></div><div>Regards,<br></=
div>&rzej</div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2901_26225009.1381136771698--
.
Author: Maurice Bos <m-ou.se@m-ou.se>
Date: Mon, 7 Oct 2013 11:13:58 +0200
Raw View
--e89a8f3b9f1db0ddcd04e823134c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It might be more useful in the form of: static_assert(!compiles{ fun<1>();
}, "What happened?");
Here, compiles{} gives a boolean. I'm not saying it'd be a good idea to
have this new type of expression in the language, but I'd prefer it over
'assert_static_failure' as it is more general and could be of use in other
contexts.
2013/10/7 Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com>
> Hi All,
> I wanted to share an idea about a new language feature that I have been
> missing for some time.
>
> Motivation:
>
> One of the features offered by a statically typed language (and in fact,
> probably the most important one) is a guarantee that certain declarations
> or expressions will fail to compile. For instance, imagine that we had SI
> units in the language:
>
> * Length l =3D 1m;
> *
> * Duration t =3D 1s;
> *
> * t + l;* // compile time error -- a nice feature
>
> As a library (especially a generic library) author, I would like to be
> able to test if I correctly provide this safety feature guarantee. Namely=
,
> I would like to be able to verify if certain constructs in code fail to
> compile.
>
> Proposal:
>
> I imagine that this could be implemented by making a "branch" in the
> compilation process when the code requests one. The compilation of the
> "trunk" is suspended. Template instantiations and ODR usages performed fr=
om
> now on, are not visible in "trunk". The compilation in the "branch"
> continues until one of the two happens:
>
> 1. We get a compilation error.
> 2. We compiled successfully everything in the branch.
>
> In the first case we stop compiling the "branch" and proceed to compile
> the "trunk" from where we suspended. Everything is fine.
>
> In the second case, we trigger a compile-time error in the "trunk" with a
> user-provided error message.
>
> How an additional language to support this feature would look, is depicte=
d
> in the following examples. I used an extra keyword *assert_static_failure=
*
> :
>
> * template <typename T>
> struct IsTrue;
>
> *
> * template<>
> *
> * struct IsTrue<true>
> {
> *
> * constexpr static bool value =3D true;
> ** };
> *
> *
> assert_static_failure ("test IsTrue") {
> *
> * IsTrue<(3 =3D=3D 1)>::value;
> *
> } // compiles fine: no effect, no symbols ODR used or templates
> instantiated
>
> *assert_static_failure ("test IsTrue - err") {
> IsTrue<(1 =3D=3D 1)>::value;
> *
> * }* // compile-time error: a failure was asserted, but no failure
> occurred
>
> another example:
>
> *template <int N>
> *
> * void fun()
> {
> *
> * static_assert (N !=3D 0, "N must be non-zero");
> *
> * }
>
> assert_static_failure ("test N =3D=3D 0") {
> *
> * fun<0>();
> *
> * }* // compiles fine
>
> *assert_static_failure ("test N !=3D 0") {
> *
> * fun<1>();
> *
> * }* // error: expected a failure
>
>
> I wanted to check in this list, if this is a feature worth standardizing,
> and if it is worth pursuing with this idea.
>
> Regards,
> &rzej
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--e89a8f3b9f1db0ddcd04e823134c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It might be more useful in the form of: static_assert(!com=
piles{ fun<1>(); }, "What happened?");<br><br>Here, compile=
s{} gives a boolean. I'm not saying it'd be a good idea to have thi=
s new type of expression in the language, but I'd prefer it over 'a=
ssert_static_failure' as it is more general and could be of use in othe=
r contexts.<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/10=
/7 Andrzej Krzemie=C5=84ski <span dir=3D"ltr"><<a href=3D"mailto:akrzemi=
1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a>></span><br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div dir=3D"ltr"><div><div><div>Hi All,<br>I wanted to share an idea about =
a new language feature that I have been missing for some time.<br><br>Motiv=
ation:<br><br>One
of the features offered by a statically typed language (and in fact,=20
probably the most important one) is a guarantee that certain=20
declarations or expressions will fail to compile. For instance, imagine tha=
t we had SI units in the language:<br><br></div><div><b>=C2=A0 Length l =3D=
1m;<br></b></div><div><b>=C2=A0 Duration t =3D 1s;<br></b></div><div><b>=
=C2=A0 t + l;</b> // compile time error -- a nice feature<br>
<br></div><div>As a library (especially a generic library) author, I would =
like to be able to test if I correctly provide this safety feature guarante=
e. Namely, I would like to be able to verify if certain constructs in code =
fail to compile.<br>
<br></div><div>Proposal:<br><br></div><div>I imagine that this could be imp=
lemented=20
by making a "branch" in the compilation process when the code req=
uests=20
one. The compilation of the "trunk" is suspended. Template=20
instantiations and ODR usages performed from now on, are not visible in=20
"trunk". The compilation in the "branch" continues unti=
l one of the two=20
happens:<br><br></div><div>=C2=A0 1. We get a compilation error.<br></div><=
div>=C2=A0 2. We compiled successfully everything in the branch.<br><br></d=
iv><div>In the first case we stop compiling the "branch" and proc=
eed to compile the "trunk" from where we suspended. Everything is=
fine.<br>
<br></div><div>In the second case, we trigger a compile-time error in the &=
quot;trunk" with a user-provided error message. <br><br></div><div>How=
an additional language to support this feature would look, is depicted in =
the following examples. I used an extra keyword <b>assert_static_failure</b=
>:<br>
</div><div><br><b>=C2=A0 template <typename T><br>=C2=A0 struct IsTru=
e;<br><br></b></div><b>=C2=A0 template<><br></b></div><b>=C2=A0 struc=
t IsTrue<true><br>=C2=A0 {<br></b></div><b>=C2=A0=C2=A0=C2=A0 constex=
pr static bool value =3D true;<br></b><b>=C2=A0 };<br>
</b><div><b><br>=C2=A0 assert_static_failure ("test IsTrue") {<br=
></b></div><div><b>=C2=A0=C2=A0=C2=A0 IsTrue<(3 =3D=3D 1)>::value;<br=
></b></div><div>=C2=A0 } // compiles fine: no effect, no symbols ODR used o=
r templates instantiated<br>
<br>=C2=A0 <b>assert_static_failure ("test IsTrue - err") {<br>=
=C2=A0=C2=A0=C2=A0 IsTrue<(1 =3D=3D 1)>::value;<br></b></div><div><b>=
=C2=A0 }</b> // compile-time error: a failure was asserted, but no failure =
occurred<br><br></div><div>
another example:<br></div><div><br></div><div>=C2=A0 <b>template <int N&=
gt;<br></b></div><div><b>=C2=A0 void fun()<br>=C2=A0 {<br></b></div><div><b=
>=C2=A0=C2=A0=C2=A0 static_assert (N !=3D 0, "N must be non-zero"=
);<br></b></div><div><b>=C2=A0 }<br>
<br>=C2=A0 assert_static_failure ("test N =3D=3D 0") {<br></b></d=
iv><div><b>=C2=A0=C2=A0=C2=A0 fun<0>();<br></b></div><div><b>=C2=A0 }=
</b> // compiles fine<br><br>=C2=A0 <b>assert_static_failure ("test N =
!=3D 0") {<br></b><div><b>=C2=A0=C2=A0=C2=A0 fun<1>();<br>
</b></div><b>=C2=A0 }</b> // error: expected a failure<br><br><br></div><di=
v>I wanted to check in this list, if this is a feature worth standardizing,=
and if it is worth pursuing with this idea.<br><br></div><div>Regards,<br>
</div>
&rzej</div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=C2=A0<br>
--- <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%2Bunsubscribe@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--e89a8f3b9f1db0ddcd04e823134c--
.
Author: Evgeny Panasyuk <evgeny.panasyuk@gmail.com>
Date: Mon, 7 Oct 2013 10:10:17 -0700 (PDT)
Raw View
------=_Part_37_6247567.1381165817914
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
7 oct 2013 =D0=B3., 13:06:11 UTC+4 Andrzej Krzemie=C5=84ski:
> I wanted to check in this list, if this is a feature worth standardizing,=
=20
> and if it is worth pursuing with this idea.
>
Have you considered requires expression from Concepts Lite proposal?=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3701.pdf - page 6=
=20
static_assert
(
!requires(Length l, Duration t)
{
t + l;
},
""
);
I think it will cover at least some of use cases of assert_static_failure.
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_37_6247567.1381165817914
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">7 oct 2013 =D0=B3., 13:06:11 UTC+4 Andrzej Krzemie=C5=
=84ski:<br><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"><d=
iv>I wanted to check in this list, if this is a feature worth standardizing=
, and if it is worth pursuing with this idea.</div></div></blockquote><div>=
<br>Have you considered requires expression from Concepts Lite proposal? ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3701.pdf - page 6 <b=
r><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250);=
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpretty=
print"><span style=3D"color: #008;" class=3D"styled-by-prettify">static_ass=
ert</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">!</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">requires</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Length</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> l</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: #606;" class=3D"styled-by=
-prettify">Duration</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> t</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
; t </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> l</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> =
</span><span style=3D"color: #080;" 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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></div></co=
de></div>I think it will cover at least some of use cases of assert_static_=
failure.<br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_37_6247567.1381165817914--
.
Author: Evgeny Panasyuk <evgeny.panasyuk@gmail.com>
Date: Mon, 7 Oct 2013 10:14:48 -0700 (PDT)
Raw View
------=_Part_11_3657077.1381166088880
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
7 oct 2013 =C7., 13:13:58 UTC+4 Maurice Bos:
>
> It might be more useful in the form of: static_assert(!compiles{ fun<1>()=
;=20
> }, "What happened?");
>
> Here, compiles{} gives a boolean. I'm not saying it'd be a good idea to=
=20
> have this new type of expression in the language, but I'd prefer it over=
=20
> 'assert_static_failure' as it is more general and could be of use in othe=
r=20
> contexts.
>
I agree - compiles{...} would be more generally applicable.
I think it is even possible to implement it in C++11 to some extent via=20
decltype + SFINAE.
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_11_3657077.1381166088880
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">7 oct 2013 =C7., 13:13:58 UTC+4 Maurice Bos:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">It might be more usefu=
l in the form of: static_assert(!compiles{ fun<1>(); }, "What happene=
d?");<br><br>Here, compiles{} gives a boolean. I'm not saying it'd be a goo=
d idea to have this new type of expression in the language, but I'd prefer =
it over 'assert_static_failure' as it is more general and could be of use i=
n other contexts.<br></div></blockquote><div><br>I agree - compiles{...}&nb=
sp; would be more generally applicable.<br>I think it is even possible to i=
mplement it in C++11 to some extent via decltype + SFINAE.<br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_11_3657077.1381166088880--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 7 Oct 2013 10:17:15 -0700 (PDT)
Raw View
------=_Part_57_6269150.1381166235850
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=C5=82ek, 7 pa=C5=BAdziernika 2013 19:14:48 UTC+2 u=C5=BCyt=
kownik Evgeny=20
Panasyuk napisa=C5=82:
>
> 7 oct 2013 =D0=B3., 13:13:58 UTC+4 Maurice Bos:
>>
>> It might be more useful in the form of: static_assert(!compiles{=20
>> fun<1>(); }, "What happened?");
>>
>> Here, compiles{} gives a boolean. I'm not saying it'd be a good idea to=
=20
>> have this new type of expression in the language, but I'd prefer it over=
=20
>> 'assert_static_failure' as it is more general and could be of use in oth=
er=20
>> contexts.
>>
>
> I agree - compiles{...} would be more generally applicable.
> I think it is even possible to implement it in C++11 to some extent via=
=20
> decltype + SFINAE.
>
Yes, "to some extent" only. It will not cover (and nor will concepts, I=20
think) the cases, where the specialization of the template exists, but has=
=20
a static_assert inside, whose failure I would also want to detect.=20
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_57_6269150.1381166235850
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu poniedzia=C5=82ek, 7 pa=C5=BAdziernika 2013=
19:14:48 UTC+2 u=C5=BCytkownik Evgeny Panasyuk napisa=C5=82:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">7 oct 2013 =D0=B3., 13=
:13:58 UTC+4 Maurice Bos:<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">It might be more useful in the form of: static_assert(!compiles{ f=
un<1>(); }, "What happened?");<br><br>Here, compiles{} gives a boolea=
n. I'm not saying it'd be a good idea to have this new type of expression i=
n the language, but I'd prefer it over 'assert_static_failure' as it is mor=
e general and could be of use in other contexts.<br></div></blockquote><div=
><br>I agree - compiles{...} would be more generally applicable.<br>I=
think it is even possible to implement it in C++11 to some extent via decl=
type + SFINAE.<br></div></div></blockquote><div><br>Yes, "to some extent" o=
nly. It will not cover (and nor will concepts, I think) the cases, where th=
e specialization of the template exists, but has a static_assert inside, wh=
ose failure I would also want to detect. <br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_57_6269150.1381166235850--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Mon, 07 Oct 2013 19:40:30 +0200
Raw View
This is a multi-part message in MIME format.
--------------030905000907080502080800
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 07/10/13 11:06, Andrzej Krzemie=C5=84ski a =C3=A9crit :
> Hi All,
> I wanted to share an idea about a new language feature that I have=20
> been missing for some time.
>
> Motivation:
>
> One of the features offered by a statically typed language (and in=20
> fact, probably the most important one) is a guarantee that certain=20
> declarations or expressions will fail to compile. For instance,=20
> imagine that we had SI units in the language:
>
> * Length l =3D 1m;
> *
> * Duration t =3D 1s;
> *
> * t + l;* // compile time error -- a nice feature
>
> As a library (especially a generic library) author, I would like to be=20
> able to test if I correctly provide this safety feature guarantee.=20
> Namely, I would like to be able to verify if certain constructs in=20
> code fail to compile.
>
> Proposal:
>
> I imagine that this could be implemented by making a "branch" in the=20
> compilation process when the code requests one. The compilation of the=20
> "trunk" is suspended. Template instantiations and ODR usages performed=20
> from now on, are not visible in "trunk". The compilation in the=20
> "branch" continues until one of the two happens:
>
> 1. We get a compilation error.
> 2. We compiled successfully everything in the branch.
>
> In the first case we stop compiling the "branch" and proceed to=20
> compile the "trunk" from where we suspended. Everything is fine.
>
> In the second case, we trigger a compile-time error in the "trunk"=20
> with a user-provided error message.
>
Hi,
I think this will really useful. Currently we need to write a program=20
and check that the compilation fails. This has some drawbacks:
* we need a program by compile error case.
* the program can compile fail due to other errors.
> How an additional language to support this feature would look, is=20
> depicted in the following examples. I used an extra keyword=20
> *assert_static_failure*:
> **<snip>
>
> *template <int N>
> *
> * void fun()
> {
> *
> * static_assert (N !=3D 0, "N must be non-zero");
> *
> * }
>
> assert_static_failure ("test N =3D=3D 0") {
> *
> * fun<0>();
> *
> * }* // compiles fine
>
What about
* compile_fails "test N =3D=3D 0" {
*
* fun<0>();
*
* }* // compiles fine
> I wanted to check in this list, if this is a feature worth=20
> standardizing, and if it is worth pursuing with this idea.
+1
Best,
Vicente
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------030905000907080502080800
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 07/10/13 11:06, Andrzej Krzemie=C5=84=
ski
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:c6186936-3ca9-481c-a43e-70c8923d2458@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>
<div>Hi All,<br>
I wanted to share an idea about a new language feature
that I have been missing for some time.<br>
<br>
Motivation:<br>
<br>
One of the features offered by a statically typed language
(and in fact, probably the most important one) is a
guarantee that certain declarations or expressions will
fail to compile. For instance, imagine that we had SI
units in the language:<br>
<br>
</div>
<div><b>=C2=A0 Length l =3D 1m;<br>
</b></div>
<div><b>=C2=A0 Duration t =3D 1s;<br>
</b></div>
<div><b>=C2=A0 t + l;</b> // compile time error -- a nice featu=
re<br>
<br>
</div>
<div>As a library (especially a generic library) author, I
would like to be able to test if I correctly provide this
safety feature guarantee. Namely, I would like to be able
to verify if certain constructs in code fail to compile.<br>
<br>
</div>
<div>Proposal:<br>
<br>
</div>
<div>I imagine that this could be implemented by making a
"branch" in the compilation process when the code requests
one. The compilation of the "trunk" is suspended. Template
instantiations and ODR usages performed from now on, are
not visible in "trunk". The compilation in the "branch"
continues until one of the two happens:<br>
<br>
</div>
<div>=C2=A0 1. We get a compilation error.<br>
</div>
<div>=C2=A0 2. We compiled successfully everything in the branc=
h.<br>
<br>
</div>
<div>In the first case we stop compiling the "branch" and
proceed to compile the "trunk" from where we suspended.
Everything is fine.<br>
<br>
</div>
<div>In the second case, we trigger a compile-time error in
the "trunk" with a user-provided error message. <br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
Hi,<br>
<br>
I think this will really useful. Currently we need to write a
program and check that the compilation fails. This has some
drawbacks:<br>
* we need a program by compile error case.<br>
* the program can compile fail due to other errors.<br>
<blockquote
cite=3D"mid:c6186936-3ca9-481c-a43e-70c8923d2458@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>
<div>How an additional language to support this feature
would look, is depicted in the following examples. I used
an extra keyword <b>assert_static_failure</b>:<br>
</div>
<div><b></b><snip><br>
</div>
</div>
</div>
<br>
<div>=C2=A0 <b>template <int N><br>
</b></div>
<div><b>=C2=A0 void fun()<br>
=C2=A0 {<br>
</b></div>
<div><b>=C2=A0=C2=A0=C2=A0 static_assert (N !=3D 0, "N must be non-=
zero");<br>
</b></div>
<div><b>=C2=A0 }<br>
<br>
=C2=A0 assert_static_failure ("test N =3D=3D 0") {<br>
</b></div>
<div><b>=C2=A0=C2=A0=C2=A0 fun<0>();<br>
</b></div>
<div><b>=C2=A0 }</b> // compiles fine<br>
<br>
</div>
</div>
</blockquote>
What about <br>
<br>
<b>=C2=A0 compile_fails "test N =3D=3D 0" {<br>
</b>
<div><b>=C2=A0=C2=A0=C2=A0 fun<0>();<br>
</b></div>
<div><b>=C2=A0 }</b> // compiles fine<br>
</div>
<br>
<blockquote
cite=3D"mid:c6186936-3ca9-481c-a43e-70c8923d2458@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>I wanted to check in this list, if this is a feature worth
standardizing, and if it is worth pursuing with this idea.<br>
</div>
</div>
</blockquote>
<br>
+1 <br>
<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------030905000907080502080800--
.
Author: Evgeny Panasyuk <evgeny.panasyuk@gmail.com>
Date: Mon, 7 Oct 2013 10:45:56 -0700 (PDT)
Raw View
------=_Part_81_6153246.1381167957080
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
7 oct 2013 =D0=B3., 21:17:15 UTC+4 Andrzej Krzemie=C5=84ski:
> Yes, "to some extent" only. It will not cover (and nor will concepts, I=
=20
> think) the cases, where the specialization of the template exists, but ha=
s=20
> a static_assert inside, whose failure I would also want to detect.=20
>
I have just checked N3701 page 45 - yes, looks like requires expression=20
relies on same rules as SFINAE:
"If the instantiation of the constraint results in a substitution failure,=
=20
the the requirement is not satisfied."
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_81_6153246.1381167957080
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">7 oct 2013 =D0=B3., 21:17:15 UTC+4 Andrzej Krzemie=C5=
=84ski:<br><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"><d=
iv>Yes, "to some extent" only. It will not cover (and nor will concepts, I =
think) the cases, where the specialization of the template exists, but has =
a static_assert inside, whose failure I would also want to detect. <br></di=
v></div></blockquote><div><br>I have just checked N3701 page 45 - yes, look=
s like requires expression relies on same rules as SFINAE:<br>"If the insta=
ntiation of the constraint results in a substitution failure, the the requi=
rement is not satisfied."<br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_81_6153246.1381167957080--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Mon, 7 Oct 2013 19:47:27 +0200
Raw View
2013/10/7 Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com>:
>
> Yes, "to some extent" only. It will not cover (and nor will concepts, I
> think) the cases, where the specialization of the template exists, but ha=
s a
> static_assert inside, whose failure I would also want to detect.
You won't get that. What you are asking for is often named
"speculative compilation/instantiation". During the C++11 development
such models where considered but rejected because of the costs to
implement that. The Core language really doesn't want this. This was
also the reason why specific issues where added in the library to
address such things:
http://cplusplus.github.io/LWG/lwg-defects.html#975
http://cplusplus.github.io/LWG/lwg-defects.html#1390
- Daniel
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: MJanes <max.jns@gmail.com>
Date: Tue, 8 Oct 2013 00:15:41 -0700 (PDT)
Raw View
------=_Part_53_21355044.1381216541880
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Il giorno luned=EC 7 ottobre 2013 19:47:27 UTC+2, Daniel Kr=FCgler ha scrit=
to:
> You won't get that. What you are asking for is often named=20
> "speculative compilation/instantiation".=20
>
even simply detecting static_assert failures ? I mean, as other said,=20
currently SFINAE it's the only tecnique usable to test expected compilation=
=20
failure ( apart specialized unit tests ) and the inability of detecting=20
static assertion is a real problem IMHO.
Considering that you can often ( always? ) turn any static assert into a=20
sfinae failure with equivalent behavior ( at least with respect to=20
detecting the error one is interested in ), I wonder why detecting static=
=20
asserts ( and only them, not any possible non-well-formedness ) would=20
qualify as speculative compilation ...=20
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_53_21355044.1381216541880
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno luned=EC 7 ottobre 2013 19:47:27 UTC+2, Daniel K=
r=FCgler ha scritto:<br><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">You wo=
n't get that. What you are asking for is often named
<br>"speculative compilation/instantiation". <br></blockquote><div><br>even=
simply detecting static_assert failures ? I mean, as other said, currently=
SFINAE it's the only tecnique usable to test expected compilation failure =
( apart specialized unit tests ) and the inability of detecting static asse=
rtion is a real problem IMHO.<br><br>Considering that you can often ( alway=
s? ) turn any static assert into a sfinae failure with equivalent behavior =
( at least with respect to detecting the error one is interested in ), I wo=
nder why detecting static asserts ( and only them, not any possible non-wel=
l-formedness ) would qualify as speculative compilation ... <br></div></div=
>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_53_21355044.1381216541880--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 09 Oct 2013 03:39:35 +0800
Raw View
On 10/7/13 5:06 PM, Andrzej Krzemie=C5=84ski wrote:
> Proposal:
>
> I imagine that this could be implemented by making a "branch" in the
> compilation process when the code requests one. The compilation of the
> "trunk" is suspended. Template instantiations and ODR usages performed fr=
om
> now on, are not visible in "trunk". The compilation in the "branch"
> continues until one of the two happens:
>
> 1. We get a compilation error.
> 2. We compiled successfully everything in the branch.
>
> In the first case we stop compiling the "branch" and proceed to compile t=
he
> "trunk" from where we suspended. Everything is fine.
Why not just use the build system to do this, and put the=20
supposed-to-fail case in a separate TU? The compiler should exit with=20
status 1 (or whatever).
There's no need to rebuild the speculation with every recompile,=20
instantiate the speculative templates, hack the ODR rule to throw them=20
away, and perhaps fundamentally change the compiler architecture to act=20
as if nothing happened. That's exactly what a build target accomplishes,=20
except it can be selective about its dependencies, and it will be=20
compiled in a parallel, separate process if it's needed at all.
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: MJanes <max.jns@gmail.com>
Date: Wed, 9 Oct 2013 00:30:41 -0700 (PDT)
Raw View
------=_Part_1103_28862665.1381303841819
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Il giorno marted=EC 8 ottobre 2013 21:39:35 UTC+2, David Krauss ha scritto:
> Why not just use the build system to do this, and put the=20
> supposed-to-fail case in a separate TU?
>
=20
because when you have to test many strictly related test cases, it's=20
natural and easier to group them together in order to reuse auxillary code=
=20
or simply present the cases in a logical "flow" ( yes, you can #include=20
and/or use conditional compilation but complexity increases, especially if=
=20
compared to the opposite situation of testing that no failure occured; it's=
=20
like having a car that runs 200 mph to the left and 10 mph to the right, an=
=20
awkward car, ain't it ? ). Can I live with this ? yes, I can, but I wonder=
=20
what's the problem in at least detecting static assert failures; say,=20
static_assert_failure(t,m) would be equivalent to static_assert(!t,m), the=
=20
only difference being that any offending static assert occuring during the=
=20
evaluation of t makes static_assert_failure succeed. Not the same thing=20
Andrzej proposed, but still very useful IMO
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1103_28862665.1381303841819
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno marted=EC 8 ottobre 2013 21:39:35 UTC+2, David K=
rauss ha scritto:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Why not j=
ust use the build system to do this, and put the=20
<br>supposed-to-fail case in a separate TU?<br></blockquote><div> <br>=
because when you have to test many strictly related test cases, it's natura=
l and easier to group them together in order to reuse auxillary code or sim=
ply present the cases in a logical "flow" ( yes, you can #include and/or us=
e conditional compilation but complexity increases, especially if compared =
to the opposite situation of testing that no failure occured; it's like hav=
ing a car that runs 200 mph to the left and 10 mph to the right, an awkward=
car, ain't it ? <font color=3D"#000066" face=3D"ARIAL" size=3D"2"></font>)=
.. Can I live with this ? yes, I can, but I wonder what's the problem in at =
least detecting static assert failures; say, static_assert_failure(t,m) wou=
ld be equivalent to static_assert(!t,m), the only difference being that any=
offending static assert occuring during the evaluation of t makes static_a=
ssert_failure succeed. Not the same thing Andrzej proposed, but still very =
useful IMO<br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1103_28862665.1381303841819--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 9 Oct 2013 09:47:23 +0200
Raw View
2013/10/8 MJanes <max.jns@gmail.com>:
> Il giorno luned=EC 7 ottobre 2013 19:47:27 UTC+2, Daniel Kr=FCgler ha scr=
itto:
>
>> You won't get that. What you are asking for is often named
>> "speculative compilation/instantiation".
>
> even simply detecting static_assert failures ? I mean, as other said,
> currently SFINAE it's the only tecnique usable to test expected compilati=
on
> failure ( apart specialized unit tests ) and the inability of detecting
> static assertion is a real problem IMHO.
Even with that, I suppose. Keep in mind that once you are enforcing
the compiler to instantiate more than needed (e.g. template
definitions compared to template declarations), this won't stop the
compiler from doing the complete job. If you have within a constructor
that direct-initializes X with Y a static_assert that validates
is_constructible<X, Y>, there is not only the failure of the
static_assert, but also the expected error or the
direct-initialization.
But that's not all: Typically the static_assert predicates are
themselves templates that need to be instantiated. What happens if
*within* this instantiation a static_assert fails? Does this have the
effect of returning false or is this a compile-error?
Current SFINAE is localized to the *immediate* context for good
reasons: It is intended to keep template compile overhead to the "top"
level.
> Considering that you can often ( always? ) turn any static assert into a
> sfinae failure with equivalent behavior ( at least with respect to detect=
ing
> the error one is interested in ), I wonder why detecting static asserts (
> and only them, not any possible non-well-formedness ) would qualify as
> speculative compilation ...
Because they (a) can occur in any instantiation depth and (b) because
the compiler still has to consider the surrounding code,
static_asserts are not isolated in general, so from a compiler
perspective there is not much difference between applying your rule
"only" to static_asserts compared to general speculative compilation.
- Daniel
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: MJanes <max.jns@gmail.com>
Date: Wed, 9 Oct 2013 01:54:01 -0700 (PDT)
Raw View
------=_Part_1253_3583587.1381308841514
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Il giorno mercoled=EC 9 ottobre 2013 09:47:23 UTC+2, Daniel Kr=FCgler ha=20
scritto:
>
> Even with that, I suppose. Keep in mind that once you are enforcing=20
> the compiler to instantiate more than needed (e.g. template=20
> definitions compared to template declarations), this won't stop the=20
> compiler from doing the complete job.=20
>
I do understand that, and I expect a compiler error if there's one. The=20
point is that it's the programmer responsability to decide which static=20
asserts are "testable" or not, and make them to not give compiler errors,=
=20
in a similar way it's the programmer responsability to write=20
asserts/exceptions correctly and eventually make sure that they're properly=
=20
and meaningfully catched in unit tests .
so, why a "static_assert_failure(t,m)" equivalent to static_assert(!t,m)=20
but the fact that it succeeds if <any> static_assert is raised during the=
=20
evaluation of t ( any other error will be the same as it already is now for=
=20
the expression static_assert(!t,m) ) would qualify as speculative=20
compilation ?=20
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1253_3583587.1381308841514
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno mercoled=EC 9 ottobre 2013 09:47:23 UTC+2, Danie=
l Kr=FCgler ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Even wi=
th that, I suppose. Keep in mind that once you are enforcing
<br>the compiler to instantiate more than needed (e.g. template
<br>definitions compared to template declarations), this won't stop the
<br>compiler from doing the complete job. <br></blockquote><div><br>I do un=
derstand that, and I expect a compiler error if there's one. The point is t=
hat it's the programmer responsability to decide which static asserts are "=
testable" or not, and make them to not give compiler errors, in a similar w=
ay it's the programmer responsability to write asserts/exceptions correctly=
and eventually make sure that they're properly and meaningfully catched in=
unit tests .<br><br>so, why a "static_assert_failure(t,m)" equivalent to s=
tatic_assert(!t,m) but the fact that it succeeds if <any> static_asse=
rt is raised during the evaluation of t ( any other error will be the same =
as it already is now for the expression static_assert(!t,m) ) would qualify=
as speculative compilation ? <br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1253_3583587.1381308841514--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 9 Oct 2013 11:05:25 +0200
Raw View
2013/10/9 MJanes <max.jns@gmail.com>:
> Il giorno mercoled=EC 9 ottobre 2013 09:47:23 UTC+2, Daniel Kr=FCgler ha
> scritto:
>>
>> Even with that, I suppose. Keep in mind that once you are enforcing
>> the compiler to instantiate more than needed (e.g. template
>> definitions compared to template declarations), this won't stop the
>> compiler from doing the complete job.
>
> I do understand that, and I expect a compiler error if there's one. The
> point is that it's the programmer responsability to decide which static
> asserts are "testable" or not, and make them to not give compiler errors,=
in
> a similar way it's the programmer responsability to write asserts/excepti=
ons
> correctly and eventually make sure that they're properly and meaningfully
> catched in unit tests .
Given that discrimination of different static_assert forms I don't see
a good reason why the programmer would not simply take the
compile-time predicate of that special static_assert and use it as the
argument of enable_if in the template declaration.
> so, why a "static_assert_failure(t,m)" equivalent to static_assert(!t,m) =
but
> the fact that it succeeds if <any> static_assert is raised during the
> evaluation of t ( any other error will be the same as it already is now f=
or
> the expression static_assert(!t,m) ) would qualify as speculative
> compilation ?
I don't understand this part.
- Daniel
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: MJanes <max.jns@gmail.com>
Date: Wed, 9 Oct 2013 03:01:34 -0700 (PDT)
Raw View
------=_Part_149_3957087.1381312894819
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Il giorno mercoled=EC 9 ottobre 2013 11:05:25 UTC+2, Daniel Kr=FCgler ha=20
scritto:
>
> Given that discrimination of different static_assert forms I don't see=20
> a good reason why the programmer would not simply take the=20
> compile-time predicate of that special static_assert and use it as the=20
> argument of enable_if in the template declaration.=20
>
for example, consider a class template that signal a semantic error of the=
=20
template arguments via possibly many static_asserts ( for example,=20
"invalid" (partial) specilizations may have simply empty bodies with just a=
=20
static assert saying something like "this or that is not allowed" ). Yes,=
=20
one can always write a predicate to test this, but why do I have to=20
duplicate code when I can just write a static_assert_failure() ?=20
I don't understand this part.=20
>
sorry, I meant to say: given a diagnostic message M, a constexpr predicate=
=20
P, and let PP be the same predicate pretending no static_asserts declared,
is it technically possible to implement a "static_assert_failure(P,M)" such=
=20
as
a) if P is well formed and holds true an error occurs with diagnostic=20
message M
b) if P is well formed and holds false no error occurs
c) if PP is ill formed errors occur as in "static_assert(!PP,M);"
d) if P is ill formed and PP is well formed an error occurs with diagnostic=
=20
message M=20
--=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_149_3957087.1381312894819
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno mercoled=EC 9 ottobre 2013 11:05:25 UTC+2, Danie=
l Kr=FCgler ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Given t=
hat discrimination of different static_assert forms I don't see
<br>a good reason why the programmer would not simply take the
<br>compile-time predicate of that special static_assert and use it as the
<br>argument of enable_if in the template declaration.
<br></blockquote><div><br>for example, consider a class template that signa=
l a semantic error of the template arguments via possibly many static_asser=
ts ( for example, "invalid" (partial) specilizations may have simply empty =
bodies with just a static assert saying something like "this or that is not=
allowed" ). Yes, one can always write a predicate to test this, but why do=
I have to duplicate code when I can just write a static_assert_failure() ?=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I don't underst=
and this part.
<br></blockquote><div><br>sorry, I meant to say: given a diagnostic message=
M, a constexpr predicate P, and let PP be the same predicate pretending no=
static_asserts declared,<br><br>is it technically possible to implement a =
"static_assert_failure(P,M)" such as<br><br>a) if P is well formed and hold=
s true an error occurs with diagnostic message M<br>b) if P is well formed =
and holds false no error occurs<br>c) if PP is ill formed errors occur as i=
n "static_assert(!PP,M);"<br>d) if P is ill formed and PP is well formed an=
error occurs with diagnostic message M <br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_149_3957087.1381312894819--
.