Topic: no contract-based optimizations?
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 13 Mar 2017 16:35:07 -0700 (PDT)
Raw View
------=_Part_2343_1421706886.1489448107310
Content-Type: multipart/alternative;
boundary="----=_Part_2344_1647804884.1489448107310"
------=_Part_2344_1647804884.1489448107310
Content-Type: text/plain; charset=UTF-8
Hi Everyone,
The first attempt at providing wording for Contracts (p0542r0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html>)
says about evaluating the contract-expressions at run-time, ability to turn
off these evaluations, but doesn't mention the ability to perform compiler
optimizations based on the contract-expressions. Is this intentional? This
was brought up in the discussion about standardizing attribute
[[unreachable]], which gives the compiler an optimization hint. Contracts
have a similar capability of allowing the optimizer to make certain
assumptions. Has this path for contracts been considered? Has it been
explicitly rejected?
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/03629320-fbe6-4e00-9a5e-0f4814e5f584%40isocpp.org.
------=_Part_2344_1647804884.1489448107310
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Everyone,<br>The first attempt at providing wording for=
Contracts (<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
017/p0542r0.html">p0542r0</a>) says about evaluating the contract-expressio=
ns at run-time, ability to turn off these evaluations, but doesn't ment=
ion the ability to perform compiler optimizations based on the contract-exp=
ressions. Is this intentional? This was brought up in the discussion about =
standardizing attribute [[unreachable]], which gives the compiler an optimi=
zation hint. Contracts have a similar capability of allowing the optimizer =
to make certain assumptions. Has this path for contracts been considered? H=
as it been explicitly rejected?<br><br>Regards,<br>&rzej;<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/03629320-fbe6-4e00-9a5e-0f4814e5f584%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/03629320-fbe6-4e00-9a5e-0f4814e5f584=
%40isocpp.org</a>.<br />
------=_Part_2344_1647804884.1489448107310--
------=_Part_2343_1421706886.1489448107310--
.
Author: Gor Nishanov <gornishanov@gmail.com>
Date: Mon, 13 Mar 2017 16:52:16 -0700 (PDT)
Raw View
------=_Part_10909_1361225522.1489449136483
Content-Type: multipart/alternative;
boundary="----=_Part_10910_1080262810.1489449136483"
------=_Part_10910_1080262810.1489449136483
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Here is some optimization relevant snippets from the contract discussion in=
=20
Kona 2017
- X: For the axiom level, is the intent that the optimizer can use this=
=20
information? (Answer: Yes)
- Y: I heard that yes, but the design paper says that the checking an=20
axiom contract is undefined behavior.
- Z: You will never generate code for an axiom contract, but the=20
compiler is allowed to use it.
- ZZ: The compiler can use axioms to optimize, can it use all the=20
conditions.
=20
Are you thinking of adding some normative wording to the paper to make sure=
=20
optimization use is not precluded?
On Monday, March 13, 2017 at 4:35:07 PM UTC-7, Andrzej Krzemie=C5=84ski wro=
te:
>
> Hi Everyone,
> The first attempt at providing wording for Contracts (p0542r0=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html>)=
=20
> says about evaluating the contract-expressions at run-time, ability to tu=
rn=20
> off these evaluations, but doesn't mention the ability to perform compile=
r=20
> optimizations based on the contract-expressions. Is this intentional? Thi=
s=20
> was brought up in the discussion about standardizing attribute=20
> [[unreachable]], which gives the compiler an optimization hint. Contracts=
=20
> have a similar capability of allowing the optimizer to make certain=20
> assumptions. Has this path for contracts been considered? Has it been=20
> explicitly rejected?
>
> Regards,
> &rzej;
>
>
--=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/65fd0018-e192-428c-b381-8df30fb6edf4%40isocpp.or=
g.
------=_Part_10910_1080262810.1489449136483
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><font color=3D"#000000" face=3D"arial, verdana, sans-=
serif"><span style=3D"font-size: 13.65px;">Here is some optimization releva=
nt snippets from the contract discussion in Kona 2017</span></font></div><u=
l style=3D"color: rgb(0, 0, 0); font-family: arial, verdana, sans-serif; fo=
nt-size: 13.65px;"><li style=3D"background-color: transparent;">X: For the =
axiom level, is the intent that the optimizer can use this information? (An=
swer: Yes)</li><li style=3D"background-color: transparent;">Y: I heard that=
yes, but the design paper says that the checking an axiom contract is unde=
fined behavior.</li><li style=3D"background-color: transparent;">Z: You wil=
l never generate code for an axiom contract, but the compiler is allowed to=
use it.</li><li style=3D"background-color: transparent;">ZZ: The compiler =
can use axioms to optimize, can it use all the conditions.<br></li></ul><di=
v>Are you thinking of adding some normative wording to the paper to make su=
re optimization use is not precluded?</div><br>On Monday, March 13, 2017 at=
4:35:07 PM UTC-7, Andrzej Krzemie=C5=84ski wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr">Hi Everyone,<br>The first attempt at p=
roviding wording for Contracts (<a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2017/p0542r0.html" target=3D"_blank" rel=3D"nofollow" on=
mousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fw=
ww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0542r0.html\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEJNud7AqJtcFj3C6c2OKL6v1ZlmA';r=
eturn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhtt=
p%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0=
542r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEJNud7AqJtcFj3C6c2OKL6v1=
ZlmA';return true;">p0542r0</a>) says about evaluating the contract-exp=
ressions at run-time, ability to turn off these evaluations, but doesn'=
t mention the ability to perform compiler optimizations based on the contra=
ct-expressions. Is this intentional? This was brought up in the discussion =
about standardizing attribute [[unreachable]], which gives the compiler an =
optimization hint. Contracts have a similar capability of allowing the opti=
mizer to make certain assumptions. Has this path for contracts been conside=
red? Has it been explicitly rejected?<br><br>Regards,<br>&rzej;<br><br>=
</div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/65fd0018-e192-428c-b381-8df30fb6edf4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/65fd0018-e192-428c-b381-8df30fb6edf4=
%40isocpp.org</a>.<br />
------=_Part_10910_1080262810.1489449136483--
------=_Part_10909_1361225522.1489449136483--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 13 Mar 2017 17:14:34 -0700 (PDT)
Raw View
------=_Part_3696_835950307.1489450474938
Content-Type: multipart/alternative;
boundary="----=_Part_3697_1750573582.1489450474938"
------=_Part_3697_1750573582.1489450474938
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu wtorek, 14 marca 2017 00:52:16 UTC+1 u=C5=BCytkownik Gor Nishanov na=
pisa=C5=82:
>
> Here is some optimization relevant snippets from the contract discussion=
=20
> in Kona 2017
>
> - X: For the axiom level, is the intent that the optimizer can use=20
> this information? (Answer: Yes)
> - Y: I heard that yes, but the design paper says that the checking an=
=20
> axiom contract is undefined behavior.
> - Z: You will never generate code for an axiom contract, but the=20
> compiler is allowed to use it.
> - ZZ: The compiler can use axioms to optimize, can it use all the=20
> conditions.
> =20
> Are you thinking of adding some normative wording to the paper to make=20
> sure optimization use is not precluded?
>
Thank you for the prompt response. My first goal is to check the authors'=
=20
intentions. According to the contracts discussions you have quoted,=20
allowing contract-based optimizations was the goal. But the wording=20
disallows them: not directly, but quite unambiguously. Also other=20
discussions I witnessed recently about prohibiting UB-based optimizations=
=20
lead me into thinking that this prohibition of "over-aggressive"=20
optimizations may be intentional.
If the committee members are in consensus to add the contract-based=20
optimizations, I indeed believe they should be explicitly allowed in the=20
standard (I would be only too happy to offer a formal wording). And there=
=20
is no reason to narrow them only to axiom-level contracts.:
T& vector<T>::operator[](size_t i)=20
[[expects: i < this->size()]]
;
This precondition has level "default", but it seams logical and natural for=
=20
me to assume that:
- in test builds, this does a defensive check
- in release builds, it just skips the check
- in super-optimized builds, the check is not only skipped, but the=20
expression is also used as additional input for optimizations in other,=
=20
even remote, parts of the program.
Regards,
&rzej;
--=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/09e50a98-cdd3-4ad1-8ffb-f12ca6f5dc19%40isocpp.or=
g.
------=_Part_3697_1750573582.1489450474938
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu wtorek, 14 marca 2017 00:52:16 UTC+1 u=C5=
=BCytkownik Gor Nishanov napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><font face=3D"arial, verdana, sans-serif" col=
or=3D"#000000"><span style=3D"font-size:13.65px">Here is some optimization =
relevant snippets from the contract discussion in Kona 2017</span></font></=
div><ul style=3D"color:rgb(0,0,0);font-family:arial,verdana,sans-serif;font=
-size:13.65px"><li style=3D"background-color:transparent">X: For the axiom =
level, is the intent that the optimizer can use this information? (Answer: =
Yes)</li><li style=3D"background-color:transparent">Y: I heard that yes, bu=
t the design paper says that the checking an axiom contract is undefined be=
havior.</li><li style=3D"background-color:transparent">Z: You will never ge=
nerate code for an axiom contract, but the compiler is allowed to use it.</=
li><li style=3D"background-color:transparent">ZZ: The compiler can use axio=
ms to optimize, can it use all the conditions.<br></li></ul><div>Are you th=
inking of adding some normative wording to the paper to make sure optimizat=
ion use is not precluded?</div></div></blockquote><div><br>Thank you for th=
e prompt response. My first goal is to check the authors' intentions. A=
ccording to the contracts discussions you have quoted, allowing contract-ba=
sed optimizations was the goal. But the wording disallows them: not directl=
y, but quite unambiguously. Also other discussions I witnessed recently abo=
ut prohibiting UB-based optimizations lead me into thinking that this prohi=
bition of "over-aggressive" optimizations may be intentional.<br>=
<br>If the committee members are in consensus to add the contract-based opt=
imizations, I indeed believe they should be explicitly allowed in the stand=
ard (I would be only too happy to offer a formal wording). And there is no =
reason to narrow them only to axiom-level contracts.:<br><br><div style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"p=
rettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><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"colo=
r: #000;" class=3D"styled-by-prettify"> vector</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: #008;" class=3D"sty=
led-by-prettify">operator</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">[](</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">size_t i</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <b=
r>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[=
[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">expects</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> i </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">this</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">-></span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">size</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">()]]</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span></div></code></div><br>This precondition has level "=
default", but it seams logical and natural for me to assume that:<br><=
ul><li>in test builds, this does a defensive check</li><li>in release build=
s, it just skips the check</li><li>in super-optimized builds, the check is =
not only skipped, but the expression is also used as additional input for o=
ptimizations in other, even remote, parts of the program.</li></ul><p>Regar=
ds,</p><p>&rzej;<br></p></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/09e50a98-cdd3-4ad1-8ffb-f12ca6f5dc19%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/09e50a98-cdd3-4ad1-8ffb-f12ca6f5dc19=
%40isocpp.org</a>.<br />
------=_Part_3697_1750573582.1489450474938--
------=_Part_3696_835950307.1489450474938--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 13 Mar 2017 19:02:57 -0700 (PDT)
Raw View
------=_Part_3509_1387248742.1489456977645
Content-Type: multipart/alternative;
boundary="----=_Part_3510_1026493236.1489456977645"
------=_Part_3510_1026493236.1489456977645
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, March 13, 2017 at 8:14:35 PM UTC-4, Andrzej Krzemie=C5=84ski wro=
te:
>
>
>
> W dniu wtorek, 14 marca 2017 00:52:16 UTC+1 u=C5=BCytkownik Gor Nishanov=
=20
> napisa=C5=82:
>>
>> Here is some optimization relevant snippets from the contract discussion=
=20
>> in Kona 2017
>>
>> - X: For the axiom level, is the intent that the optimizer can use=20
>> this information? (Answer: Yes)
>> - Y: I heard that yes, but the design paper says that the checking an=
=20
>> axiom contract is undefined behavior.
>> - Z: You will never generate code for an axiom contract, but the=20
>> compiler is allowed to use it.
>> - ZZ: The compiler can use axioms to optimize, can it use all the=20
>> conditions.
>> =20
>> Are you thinking of adding some normative wording to the paper to make=
=20
>> sure optimization use is not precluded?
>>
>
> Thank you for the prompt response. My first goal is to check the authors'=
=20
> intentions. According to the contracts discussions you have quoted,=20
> allowing contract-based optimizations was the goal. But the wording=20
> disallows them: not directly, but quite unambiguously. Also other=20
> discussions I witnessed recently about prohibiting UB-based optimizations=
=20
> lead me into thinking that this prohibition of "over-aggressive"=20
> optimizations may be intentional.
>
> If the committee members are in consensus to add the contract-based=20
> optimizations, I indeed believe they should be explicitly allowed in the=
=20
> standard (I would be only too happy to offer a formal wording). And there=
=20
> is no reason to narrow them only to axiom-level contracts.:
>
> T& vector<T>::operator[](size_t i)=20
> [[expects: i < this->size()]]
> ;
>
> This precondition has level "default", but it seams logical and natural=
=20
> for me to assume that:
>
> - in test builds, this does a defensive check
> - in release builds, it just skips the check
> - in super-optimized builds, the check is not only skipped, but the=20
> expression is also used as additional input for optimizations in other=
,=20
> even remote, parts of the program.
>
>
Why would you release something that is not "super-optimized"? Or at the=20
very least, at the highest optimization level you're comfortable shipping=
=20
at. I understand that people often do testing in not-very-optimized builds,=
=20
but those aren't really "release" builds since... you know, you're not=20
*releasing* them ;)
--=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/ef5a97b8-276e-434c-98e3-dfb148e65780%40isocpp.or=
g.
------=_Part_3510_1026493236.1489456977645
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, March 13, 2017 at 8:14:35 PM UTC-4, And=
rzej Krzemie=C5=84ski wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><br><br>W dniu wtorek, 14 marca 2017 00:52:16 UTC+1 u=C5=BCy=
tkownik Gor Nishanov napisa=C5=82:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><font face=3D"arial, verdana, sans-serif" color=3D"#=
000000"><span style=3D"font-size:13.65px">Here is some optimization relevan=
t snippets from the contract discussion in Kona 2017</span></font></div><ul=
style=3D"color:rgb(0,0,0);font-family:arial,verdana,sans-serif;font-size:1=
3.65px"><li style=3D"background-color:transparent">X: For the axiom level, =
is the intent that the optimizer can use this information? (Answer: Yes)</l=
i><li style=3D"background-color:transparent">Y: I heard that yes, but the d=
esign paper says that the checking an axiom contract is undefined behavior.=
</li><li style=3D"background-color:transparent">Z: You will never generate =
code for an axiom contract, but the compiler is allowed to use it.</li><li =
style=3D"background-color:transparent">ZZ: The compiler can use axioms to o=
ptimize, can it use all the conditions.<br></li></ul><div>Are you thinking =
of adding some normative wording to the paper to make sure optimization use=
is not precluded?</div></div></blockquote><div><br>Thank you for the promp=
t response. My first goal is to check the authors' intentions. Accordin=
g to the contracts discussions you have quoted, allowing contract-based opt=
imizations was the goal. But the wording disallows them: not directly, but =
quite unambiguously. Also other discussions I witnessed recently about proh=
ibiting UB-based optimizations lead me into thinking that this prohibition =
of "over-aggressive" optimizations may be intentional.<br><br>If =
the committee members are in consensus to add the contract-based optimizati=
ons, I indeed believe they should be explicitly allowed in the standard (I =
would be only too happy to offer a formal wording). And there is no reason =
to narrow them only to axiom-level contracts.:<br><br><div style=3D"backgro=
und-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid=
;border-width:1px"><code><div><span style=3D"color:#000">T</span><span styl=
e=3D"color:#660">&</span><span style=3D"color:#000"> vector</span><span=
style=3D"color:#660"><</span><span style=3D"color:#000">T</span><span s=
tyle=3D"color:#660">>::</span><span style=3D"color:#008">operator</span>=
<span style=3D"color:#660">[](</span><span style=3D"color:#000">size_t i</s=
pan><span style=3D"color:#660">)</span><span style=3D"color:#000"> <br>=C2=
=A0 </span><span style=3D"color:#660">[[</span><span style=3D"color:#000">e=
xpects</span><span style=3D"color:#660">:</span><span style=3D"color:#000">=
i </span><span style=3D"color:#660"><</span><span style=3D"color:#000">=
</span><span style=3D"color:#008">this</span><span style=3D"color:#660">-&=
gt;</span><span style=3D"color:#000">size</span><span style=3D"color:#660">=
()]]</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"colo=
r:#660">;</span></div></code></div><br>This precondition has level "de=
fault", but it seams logical and natural for me to assume that:<br><ul=
><li>in test builds, this does a defensive check</li><li>in release builds,=
it just skips the check</li><li>in super-optimized builds, the check is no=
t only skipped, but the expression is also used as additional input for opt=
imizations in other, even remote, parts of the program.</li></ul></div></di=
v></blockquote><div><br>Why would you release something that is not "s=
uper-optimized"? Or at the very least, at the highest optimization lev=
el you're comfortable shipping at. I understand that people often do te=
sting in not-very-optimized builds, but those aren't really "relea=
se" builds since... you know, you're not <i>releasing</i> them ;)<=
br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/ef5a97b8-276e-434c-98e3-dfb148e65780%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef5a97b8-276e-434c-98e3-dfb148e65780=
%40isocpp.org</a>.<br />
------=_Part_3510_1026493236.1489456977645--
------=_Part_3509_1387248742.1489456977645--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Tue, 14 Mar 2017 01:01:26 -0700 (PDT)
Raw View
------=_Part_2488_1173895832.1489478486879
Content-Type: multipart/alternative;
boundary="----=_Part_2489_1371726297.1489478486880"
------=_Part_2489_1371726297.1489478486880
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu wtorek, 14 marca 2017 03:02:57 UTC+1 u=C5=BCytkownik Nicol Bolas nap=
isa=C5=82:
>
>
>
> On Monday, March 13, 2017 at 8:14:35 PM UTC-4, Andrzej Krzemie=C5=84ski w=
rote:
>>
>>
>>
>> W dniu wtorek, 14 marca 2017 00:52:16 UTC+1 u=C5=BCytkownik Gor Nishanov=
=20
>> napisa=C5=82:
>>>
>>> Here is some optimization relevant snippets from the contract discussio=
n=20
>>> in Kona 2017
>>>
>>> - X: For the axiom level, is the intent that the optimizer can use=
=20
>>> this information? (Answer: Yes)
>>> - Y: I heard that yes, but the design paper says that the checking=
=20
>>> an axiom contract is undefined behavior.
>>> - Z: You will never generate code for an axiom contract, but the=20
>>> compiler is allowed to use it.
>>> - ZZ: The compiler can use axioms to optimize, can it use all the=20
>>> conditions.
>>> =20
>>> Are you thinking of adding some normative wording to the paper to make=
=20
>>> sure optimization use is not precluded?
>>>
>>
>> Thank you for the prompt response. My first goal is to check the authors=
'=20
>> intentions. According to the contracts discussions you have quoted,=20
>> allowing contract-based optimizations was the goal. But the wording=20
>> disallows them: not directly, but quite unambiguously. Also other=20
>> discussions I witnessed recently about prohibiting UB-based optimization=
s=20
>> lead me into thinking that this prohibition of "over-aggressive"=20
>> optimizations may be intentional.
>>
>> If the committee members are in consensus to add the contract-based=20
>> optimizations, I indeed believe they should be explicitly allowed in the=
=20
>> standard (I would be only too happy to offer a formal wording). And ther=
e=20
>> is no reason to narrow them only to axiom-level contracts.:
>>
>> T& vector<T>::operator[](size_t i)=20
>> [[expects: i < this->size()]]
>> ;
>>
>> This precondition has level "default", but it seams logical and natural=
=20
>> for me to assume that:
>>
>> - in test builds, this does a defensive check
>> - in release builds, it just skips the check
>> - in super-optimized builds, the check is not only skipped, but the=
=20
>> expression is also used as additional input for optimizations in othe=
r,=20
>> even remote, parts of the program.
>>
>>
> Why would you release something that is not "super-optimized"? Or at the=
=20
> very least, at the highest optimization level you're comfortable shipping=
=20
> at. I understand that people often do testing in not-very-optimized build=
s,=20
> but those aren't really "release" builds since... you know, you're not=20
> *releasing* them ;)
>
This diverts the discussion from the main point, but I can't help=20
answering. I am still under the influence of another discussion on=20
isocpp-lib-ext, where I observed that some people are not comfortable with=
=20
UB-based optimizations, and in fact consider them harmful. I treat=20
contract-based optimization as the same kind. So I am currently pursuing a=
=20
compromise view: if you don't like contract-based optimizations do not use=
=20
them in your release builds; if I want to use them, let me do it. Hence,=20
the two levels of release builds: one for me, the other for "you".
Regards,
&rzej;
--=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/44d65334-1d5b-4924-8d15-b5ed5df4d7ad%40isocpp.or=
g.
------=_Part_2489_1371726297.1489478486880
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu wtorek, 14 marca 2017 03:02:57 UTC+1 u=C5=
=BCytkownik Nicol Bolas napisa=C5=82:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr"><br><br>On Monday, March 13, 2017 at 8:14:35 PM UTC=
-4, Andrzej Krzemie=C5=84ski wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><br><br>W dniu wtorek, 14 marca 2017 00:52:16 UTC+1 u=C5=
=BCytkownik Gor Nishanov napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div><font face=3D"arial, verdana, sans-serif" color=3D=
"#000000"><span style=3D"font-size:13.65px">Here is some optimization relev=
ant snippets from the contract discussion in Kona 2017</span></font></div><=
ul style=3D"color:rgb(0,0,0);font-family:arial,verdana,sans-serif;font-size=
:13.65px"><li style=3D"background-color:transparent">X: For the axiom level=
, is the intent that the optimizer can use this information? (Answer: Yes)<=
/li><li style=3D"background-color:transparent">Y: I heard that yes, but the=
design paper says that the checking an axiom contract is undefined behavio=
r.</li><li style=3D"background-color:transparent">Z: You will never generat=
e code for an axiom contract, but the compiler is allowed to use it.</li><l=
i style=3D"background-color:transparent">ZZ: The compiler can use axioms to=
optimize, can it use all the conditions.<br></li></ul><div>Are you thinkin=
g of adding some normative wording to the paper to make sure optimization u=
se is not precluded?</div></div></blockquote><div><br>Thank you for the pro=
mpt response. My first goal is to check the authors' intentions. Accord=
ing to the contracts discussions you have quoted, allowing contract-based o=
ptimizations was the goal. But the wording disallows them: not directly, bu=
t quite unambiguously. Also other discussions I witnessed recently about pr=
ohibiting UB-based optimizations lead me into thinking that this prohibitio=
n of "over-aggressive" optimizations may be intentional.<br><br>I=
f the committee members are in consensus to add the contract-based optimiza=
tions, I indeed believe they should be explicitly allowed in the standard (=
I would be only too happy to offer a formal wording). And there is no reaso=
n to narrow them only to axiom-level contracts.:<br><br><div style=3D"backg=
round-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:sol=
id;border-width:1px"><code><div><span style=3D"color:#000">T</span><span st=
yle=3D"color:#660">&</span><span style=3D"color:#000"> vector</span><sp=
an style=3D"color:#660"><</span><span style=3D"color:#000">T</span><span=
style=3D"color:#660">>::</span><span style=3D"color:#008">operator</spa=
n><span style=3D"color:#660">[](</span><span style=3D"color:#000">size_t i<=
/span><span style=3D"color:#660">)</span><span style=3D"color:#000"> <br>=
=C2=A0 </span><span style=3D"color:#660">[[</span><span style=3D"color:#000=
">expects</span><span style=3D"color:#660">:</span><span style=3D"color:#00=
0"> i </span><span style=3D"color:#660"><</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#008">this</span><span style=3D"color:#660"=
>-></span><span style=3D"color:#000">size</span><span style=3D"color:#66=
0">()]]</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"c=
olor:#660">;</span></div></code></div><br>This precondition has level "=
;default", but it seams logical and natural for me to assume that:<br>=
<ul><li>in test builds, this does a defensive check</li><li>in release buil=
ds, it just skips the check</li><li>in super-optimized builds, the check is=
not only skipped, but the expression is also used as additional input for =
optimizations in other, even remote, parts of the program.</li></ul></div><=
/div></blockquote><div><br>Why would you release something that is not &quo=
t;super-optimized"? Or at the very least, at the highest optimization =
level you're comfortable shipping at. I understand that people often do=
testing in not-very-optimized builds, but those aren't really "re=
lease" builds since... you know, you're not <i>releasing</i> them =
;)<br></div></div></blockquote><div><br>This diverts the discussion from th=
e main point, but I can't help answering. I am still under the influenc=
e of another discussion on isocpp-lib-ext, where I observed that some peopl=
e are not comfortable with UB-based optimizations, and in fact consider the=
m harmful. I treat contract-based optimization as the same kind. So I am cu=
rrently pursuing a compromise view: if you don't like contract-based op=
timizations do not use them in your release builds; if I want to use them, =
let me do it. Hence, the two levels of release builds: one for me, the othe=
r for "you".<br><br>Regards,<br>&rzej;<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/44d65334-1d5b-4924-8d15-b5ed5df4d7ad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/44d65334-1d5b-4924-8d15-b5ed5df4d7ad=
%40isocpp.org</a>.<br />
------=_Part_2489_1371726297.1489478486880--
------=_Part_2488_1173895832.1489478486879--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Tue, 14 Mar 2017 15:40:37 -0700 (PDT)
Raw View
------=_Part_13290_316904137.1489531237270
Content-Type: multipart/alternative;
boundary="----=_Part_13291_1376103185.1489531237270"
------=_Part_13291_1376103185.1489531237270
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, March 13, 2017 at 4:35:07 PM UTC-7, Andrzej Krzemie=C5=84ski wro=
te:
>
> Hi Everyone,
> The first attempt at providing wording for Contracts (p0542r0=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html>)=
=20
> says about evaluating the contract-expressions at run-time, ability to tu=
rn=20
> off these evaluations, but doesn't mention the ability to perform compile=
r=20
> optimizations based on the contract-expressions. Is this intentional? Thi=
s=20
> was brought up in the discussion about standardizing attribute=20
> [[unreachable]], which gives the compiler an optimization hint. Contracts=
=20
> have a similar capability of allowing the optimizer to make certain=20
> assumptions. Has this path for contracts been considered? Has it been=20
> explicitly rejected?
>
Sorry to piggyback with no further information, but I'm also interested in=
=20
the answer to your question (and Contracts in general).
P0542R0=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html>=20
doesn't seem to be usable in its current state, in that it never defines=20
what it means by "to check a contract". It sounds like it means "evaluating=
=20
an expression at runtime and then doing something (such as abort) if the=20
expression is falsey"; but unfortunately that's exactly the opposite of why=
=20
we generally want contracts. Generally we write down a contract so that we=
=20
*don't* have to keep checking for error conditions at runtime =E2=80=94 we =
want to=20
rely on static analysis to catch any inconsistencies in our annotations.
The place to inject static analysis into P0542R0 would be to insert some=20
wording into clause [dcl.attr.contracts] /13 that explicitly acknowledges=
=20
the possibility of providing a *violation hander* function whose behavior=
=20
is undefined. As I read it, P0542R0 is perfectly compatible with that=20
possibility. (And the stuff about "continuation modes" can safely be=20
ignored, since it's redundant with the specification of a *violation=20
handler*'s behavior.)
<rant> It's unfortunate that so much of P0542R0 is spent talking about=20
foreign, un-standardizable things like "contract levels" and "build=20
levels", instead of focusing on the C++ side of things. All that=20
build-system verbiage just makes it hard to pick out the fundamental C++=20
language changes that are being proposed =E2=80=94 and it turns out that ha=
lf of=20
the proposed additions are purely "implementation-defined" anyway. I hope=
=20
R1 will be better in both respects: less build-system cruft, more=20
well-defined behavior for the non-cruft. </rant>
My $.02,
=E2=80=93Arthur
--=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/4731e522-d71b-421a-8782-bdecddd9cd2f%40isocpp.or=
g.
------=_Part_13291_1376103185.1489531237270
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, March 13, 2017 at 4:35:07 PM UTC-7, Andrzej Krz=
emie=C5=84ski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Hi Everyone,<br>The first attempt at providing wording for Contrac=
ts (<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p054=
2r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc2=
2%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0542r0.html\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNEJNud7AqJtcFj3C6c2OKL6v1ZlmA';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2=
Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0542r0.html\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNEJNud7AqJtcFj3C6c2OKL6v1ZlmA';return true;">p054=
2r0</a>) says about evaluating the contract-expressions at run-time, abilit=
y to turn off these evaluations, but doesn't mention the ability to per=
form compiler optimizations based on the contract-expressions. Is this inte=
ntional? This was brought up in the discussion about standardizing attribut=
e [[unreachable]], which gives the compiler an optimization hint. Contracts=
have a similar capability of allowing the optimizer to make certain assump=
tions. Has this path for contracts been considered? Has it been explicitly =
rejected?<br></div></blockquote><div><br></div><div>Sorry to piggyback with=
no further information, but I'm also interested in the answer to your =
question (and Contracts in general).</div><div><a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html">P0542R0</a> doesn'=
t seem to be usable in its current state, in that it never defines what it =
means by "to check a contract". It sounds like it means "eva=
luating an expression at runtime and then doing something (such as abort) i=
f the expression is falsey"; but unfortunately that's exactly the =
opposite of why we generally want contracts. Generally we write down a cont=
ract so that we <i>don't</i> have to keep checking for error conditions=
at runtime =E2=80=94 we want to rely on static analysis to catch any incon=
sistencies in our annotations.</div><div><br></div><div>The place to inject=
static analysis into P0542R0 would be to insert some wording into clause [=
dcl.attr.contracts] /13 that explicitly acknowledges the possibility of pro=
viding a <i>violation hander</i>=C2=A0function whose behavior is undefined.=
=C2=A0As I read it, P0542R0 is perfectly compatible with that possibility.=
(And the stuff about "continuation modes" can safely be ignored,=
since it's redundant with the specification of a <i>violation handler<=
/i>'s behavior.)</div><div><br></div><div><rant> It's unfortu=
nate that so much of P0542R0 is spent talking about foreign, un-standardiza=
ble things like "contract levels" and "build levels", i=
nstead of focusing on the C++ side of things. All that build-system verbiag=
e just makes it hard to pick out the fundamental C++ language changes that =
are being proposed =E2=80=94 and it turns out that half of the proposed add=
itions are purely "implementation-defined" anyway. I hope R1 will=
be better in both respects: less build-system cruft, more well-defined beh=
avior for the non-cruft. </rant></div><div><br></div><div>My $.02,</d=
iv><div>=E2=80=93Arthur</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/4731e522-d71b-421a-8782-bdecddd9cd2f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4731e522-d71b-421a-8782-bdecddd9cd2f=
%40isocpp.org</a>.<br />
------=_Part_13291_1376103185.1489531237270--
------=_Part_13290_316904137.1489531237270--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Wed, 15 Mar 2017 01:02:22 -0700 (PDT)
Raw View
------=_Part_2747_995539496.1489564942416
Content-Type: multipart/alternative;
boundary="----=_Part_2748_541439017.1489564942416"
------=_Part_2748_541439017.1489564942416
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, March 15, 2017 at 1:40:37 AM UTC+3, Arthur O'Dwyer wrote:
>
> P0542R0=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html>=20
> doesn't seem to be usable in its current state, in that it never defines=
=20
> what it means by "to check a contract". It sounds like it means "evaluati=
ng=20
> an expression at runtime and then doing something (such as abort) if the=
=20
> expression is falsey"; but unfortunately that's exactly the opposite of w=
hy=20
> we generally want contracts. Generally we write down a contract so that w=
e=20
> *don't* have to keep checking for error conditions at runtime =E2=80=94 w=
e want=20
> to rely on static analysis to catch any inconsistencies in our annotation=
s.
>
Exactly my feeling when I was reading the paper. Why runtime checks? We can=
=20
do it already without contracts. Static analysis for compile time checks=20
and optimizations opportunity are the main reasons to introduce this=20
feature. Do we need any runtime behaviour here at all?
--=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/a13a2dbc-4d35-4cad-a2d9-01fa48578ff7%40isocpp.or=
g.
------=_Part_2748_541439017.1489564942416
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, March 15, 2017 at 1:40:37 AM UTC+3, Arthur O=
'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p054=
2r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc2=
2%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0542r0.html\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNEJNud7AqJtcFj3C6c2OKL6v1ZlmA';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2=
Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0542r0.html\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNEJNud7AqJtcFj3C6c2OKL6v1ZlmA';return true;">P054=
2R0</a> doesn't seem to be usable in its current state, in that it neve=
r defines what it means by "to check a contract". It sounds like =
it means "evaluating an expression at runtime and then doing something=
(such as abort) if the expression is falsey"; but unfortunately that&=
#39;s exactly the opposite of why we generally want contracts. Generally we=
write down a contract so that we <i>don't</i> have to keep checking fo=
r error conditions at runtime =E2=80=94 we want to rely on static analysis =
to catch any inconsistencies in our annotations.</div></blockquote><div>Exa=
ctly my feeling when I was reading the paper. Why runtime checks? We can do=
it already without contracts. Static analysis for compile time checks and =
optimizations opportunity are the main reasons to introduce this feature. D=
o we need any runtime behaviour here at all?<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/a13a2dbc-4d35-4cad-a2d9-01fa48578ff7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a13a2dbc-4d35-4cad-a2d9-01fa48578ff7=
%40isocpp.org</a>.<br />
------=_Part_2748_541439017.1489564942416--
------=_Part_2747_995539496.1489564942416--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 15 Mar 2017 02:17:15 -0700 (PDT)
Raw View
------=_Part_2833_1102553908.1489569435539
Content-Type: multipart/alternative;
boundary="----=_Part_2834_512024413.1489569435539"
------=_Part_2834_512024413.1489569435539
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu =C5=9Broda, 15 marca 2017 09:02:22 UTC+1 u=C5=BCytkownik Victor Dyac=
henko=20
napisa=C5=82:
>
> On Wednesday, March 15, 2017 at 1:40:37 AM UTC+3, Arthur O'Dwyer wrote:
>>
>> P0542R0=20
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html>=
=20
>> doesn't seem to be usable in its current state, in that it never defines=
=20
>> what it means by "to check a contract". It sounds like it means "evaluat=
ing=20
>> an expression at runtime and then doing something (such as abort) if the=
=20
>> expression is falsey"; but unfortunately that's exactly the opposite of =
why=20
>> we generally want contracts. Generally we write down a contract so that =
we=20
>> *don't* have to keep checking for error conditions at runtime =E2=80=94 =
we want=20
>> to rely on static analysis to catch any inconsistencies in our annotatio=
ns.
>>
> Exactly my feeling when I was reading the paper. Why runtime checks? We=
=20
> can do it already without contracts. Static analysis for compile time=20
> checks and optimizations opportunity are the main reasons to introduce th=
is=20
> feature. Do we need any runtime behaviour here at all?
>
The current proposal is supposed to be the result of a compromise between=
=20
two parties: one that wants the additional instrumentation in form of=20
run-time checks injected into code, the other that wants a tool for=20
human-assisted static analysis and optimizations. But from the current=20
shape is that the compromise is leaning too much towards the first party.=
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6e328bea-8cf5-446f-9153-740d197a59fe%40isocpp.or=
g.
------=_Part_2834_512024413.1489569435539
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 15 marca 2017 09:02:22 UTC+1 u=
=C5=BCytkownik Victor Dyachenko napisa=C5=82:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr">On Wednesday, March 15, 2017 at 1:40:37 AM =
UTC+3, Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers=
/2017/p0542r0.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.=
href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2F=
jtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0542r0.html\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNEJNud7AqJtcFj3C6c2OKL6v1ZlmA';return true;" oncli=
ck=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open=
-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0542r0.html\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEJNud7AqJtcFj3C6c2OKL6v1ZlmA';return t=
rue;">P0542R0</a> doesn't seem to be usable in its current state, in th=
at it never defines what it means by "to check a contract". It so=
unds like it means "evaluating an expression at runtime and then doing=
something (such as abort) if the expression is falsey"; but unfortuna=
tely that's exactly the opposite of why we generally want contracts. Ge=
nerally we write down a contract so that we <i>don't</i> have to keep c=
hecking for error conditions at runtime =E2=80=94 we want to rely on static=
analysis to catch any inconsistencies in our annotations.</div></blockquot=
e><div>Exactly my feeling when I was reading the paper. Why runtime checks?=
We can do it already without contracts. Static analysis for compile time c=
hecks and optimizations opportunity are the main reasons to introduce this =
feature. Do we need any runtime behaviour here at all?<br></div></div></blo=
ckquote><div><br>The current proposal is supposed to be the result of a com=
promise between two parties: one that wants the additional instrumentation =
in form of run-time checks injected into code, the other that wants a tool =
for human-assisted static analysis and optimizations. But from the current =
shape is that the compromise is leaning too much towards the first party. <=
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/6e328bea-8cf5-446f-9153-740d197a59fe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6e328bea-8cf5-446f-9153-740d197a59fe=
%40isocpp.org</a>.<br />
------=_Part_2834_512024413.1489569435539--
------=_Part_2833_1102553908.1489569435539--
.