------=_Part_2743_1611645563.1489031375568
Content-Type: multipart/alternative;
 boundary="----=_Part_2744_603107288.1489031375568"

------=_Part_2744_603107288.1489031375568
Content-Type: text/plain; charset=UTF-8

I wrote up a proposal document for a new attribute, [[unreachable]], which
lets you mark locations in code as being unreachable for optimization
purposes, or to suppress certain warnings.

This has been discussed on the mailing list before; there's a link to that
thread in the .pdf.

https://1drv.ms/b/s!Agwy_QljRwlGgcoJeZMiimuq3H36Ww

I have no idea what to do with it now.  If you have any comments on the
content, or how to actually proceed, let me know! =^-^=

Melissa

--
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/e6a951ab-a7eb-4bce-86fd-6988215e2309%40isocpp.org.

------=_Part_2744_603107288.1489031375568
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I wrote up a proposal document for a new attribute, [[unre=
achable]], which lets you mark locations in code as being unreachable for o=
ptimization purposes, or to suppress certain warnings.<br><br>This has been=
 discussed on the mailing list before; there&#39;s a link to that thread in=
 the .pdf.<br><br>https://1drv.ms/b/s!Agwy_QljRwlGgcoJeZMiimuq3H36Ww<br><br=
>I have no idea what to do with it now.=C2=A0 If you have any comments on t=
he content, or how to actually proceed, let me know! =3D^-^=3D<br><br>Melis=
sa<br></div>

<p></p>

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

------=_Part_2744_603107288.1489031375568--

------=_Part_2743_1611645563.1489031375568--

.

2017-03-09 4:49 GMT+01:00 Myriachan <myriachan@gmail.com>:
> I wrote up a proposal document for a new attribute, [[unreachable]], which
> lets you mark locations in code as being unreachable for optimization
> purposes, or to suppress certain warnings.
>
> This has been discussed on the mailing list before; there's a link to that
> thread in the .pdf.
>
> https://1drv.ms/b/s!Agwy_QljRwlGgcoJeZMiimuq3H36Ww
>
> I have no idea what to do with it now.  If you have any comments on the
> content, or how to actually proceed, let me know! =^-^=

Technically everything is fine, but I haven't had yet the time to read
the full content. From my view point, you should allocate a document
number via the lwgchair address for this.

Thanks,

- Daniel

--
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/CAGNvRgC_VjPD1%2Bg3gY08sNn-3i9EZ_f4bwN1RGDnWtXbTxeOhg%40mail.gmail.com.

.

--001a114342f2b573c3054a5162c1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Myriachan : if you cannot make it to Toronto, I'm willing to help your
proposal along. I have to make unpleasant contorsions in my own code due to
lack of this feature right now :)

2017-03-09 1:36 GMT-05:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com>:

> 2017-03-09 4:49 GMT+01:00 Myriachan <myriachan@gmail.com>:
> > I wrote up a proposal document for a new attribute, [[unreachable]],
> which
> > lets you mark locations in code as being unreachable for optimization
> > purposes, or to suppress certain warnings.
> >
> > This has been discussed on the mailing list before; there's a link to
> that
> > thread in the .pdf.
> >
> > https://1drv.ms/b/s!Agwy_QljRwlGgcoJeZMiimuq3H36Ww
> >
> > I have no idea what to do with it now.  If you have any comments on the
> > content, or how to actually proceed, let me know! =3D^-^=3D
>
> Technically everything is fine, but I haven't had yet the time to read
> the full content. From my view point, you should allocate a document
> number via the lwgchair address for this.
>
> Thanks,
>
> - Daniel
>
> --
> 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/CAGNvRgC_VjPD1%2Bg3gY08sNn-3i9EZ_
> f4bwN1RGDnWtXbTxeOhg%40mail.gmail.com.
>

--=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/CAKiZDp3YqnJQQmCb6b3sQwNO2zEB0nyJ3FSaKRN1Drp%3DF=
jzDYA%40mail.gmail.com.

--001a114342f2b573c3054a5162c1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Myriachan : if you cannot make it to Toronto, I&#39;m will=
ing to help your proposal along. I have to make unpleasant contorsions in m=
y own code due to lack of this feature right now :)<br></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">2017-03-09 1:36 GMT-05:00 Danie=
l Kr=C3=BCgler <span dir=3D"ltr">&lt;<a href=3D"mailto:daniel.kruegler@gmai=
l.com" target=3D"_blank">daniel.kruegler@gmail.com</a>&gt;</span>:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><span class=3D"">2017-03-09 4:49 GMT+01:00 Myriac=
han &lt;<a href=3D"mailto:myriachan@gmail.com">myriachan@gmail.com</a>&gt;:=
<br>
&gt; I wrote up a proposal document for a new attribute, [[unreachable]], w=
hich<br>
&gt; lets you mark locations in code as being unreachable for optimization<=
br>
&gt; purposes, or to suppress certain warnings.<br>
&gt;<br>
&gt; This has been discussed on the mailing list before; there&#39;s a link=
 to that<br>
&gt; thread in the .pdf.<br>
&gt;<br>
&gt; <a href=3D"https://1drv.ms/b/s!Agwy_QljRwlGgcoJeZMiimuq3H36Ww" rel=3D"=
noreferrer" target=3D"_blank">https://1drv.ms/b/s!Agwy_<wbr>QljRwlGgcoJeZMi=
imuq3H36Ww</a><br>
&gt;<br>
&gt; I have no idea what to do with it now.=C2=A0 If you have any comments =
on the<br>
&gt; content, or how to actually proceed, let me know! =3D^-^=3D<br>
<br>
</span>Technically everything is fine, but I haven&#39;t had yet the time t=
o read<br>
the full content. From my view point, you should allocate a document<br>
number via the lwgchair address for this.<br>
<br>
Thanks,<br>
<br>
- Daniel<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAGNvRgC_VjPD1%2Bg3gY08sNn-3i9=
EZ_f4bwN1RGDnWtXbTxeOhg%40mail.gmail.com" rel=3D"noreferrer" target=3D"_bla=
nk">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/=
CAGNvRgC_VjPD1%<wbr>2Bg3gY08sNn-3i9EZ_<wbr>f4bwN1RGDnWtXbTxeOhg%40mail.<wbr=
>gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

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

--001a114342f2b573c3054a5162c1--

.

------=_Part_3771_1682674114.1489113488806
Content-Type: multipart/alternative;
 boundary="----=_Part_3772_1732043852.1489113488806"

------=_Part_3772_1732043852.1489113488806
Content-Type: text/plain; charset=UTF-8

On Thursday, March 9, 2017 at 11:38:14 AM UTC-8, Patrice Roy wrote:
>
> Myriachan : if you cannot make it to Toronto, I'm willing to help your
> proposal along. I have to make unpleasant contorsions in my own code due to
> lack of this feature right now :)
>
>
Thanks; I'll keep that in mind =^-^=  I'm going to be in Minneapolis the
week before the Toronto meeting, so I'm considering extending my trip to go
to the Toronto meeting.

Melissa

--
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/efbaff3c-fc72-47d5-8ba2-3aaaec2a3d75%40isocpp.org.

------=_Part_3772_1732043852.1489113488806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 9, 2017 at 11:38:14 AM UTC-8, Patrice R=
oy 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">Myri=
achan : if you cannot make it to Toronto, I&#39;m willing to help your prop=
osal along. I have to make unpleasant contorsions in my own code due to lac=
k of this feature right now :)<br></div><div><br></div></blockquote><div><b=
r>Thanks; I&#39;ll keep that in mind =3D^-^=3D=C2=A0 I&#39;m going to be in=
 Minneapolis the week before the Toronto meeting, so I&#39;m considering ex=
tending my trip to go to the Toronto meeting.<br><br>Melissa<br></div></div=
>

<p></p>

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

------=_Part_3772_1732043852.1489113488806--

------=_Part_3771_1682674114.1489113488806--

.

------=_Part_1111_41837873.1489147477557
Content-Type: multipart/alternative;
 boundary="----=_Part_1112_45239803.1489147477558"

------=_Part_1112_45239803.1489147477558
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 9 marca 2017 04:49:35 UTC+1 u=C5=BCytkownik Myriachan napi=
sa=C5=82:
>
> I wrote up a proposal document for a new attribute, [[unreachable]], whic=
h=20
> lets you mark locations in code as being unreachable for optimization=20
> purposes, or to suppress certain warnings.
>
> This has been discussed on the mailing list before; there's a link to tha=
t=20
> thread in the .pdf.
>
> https://1drv.ms/b/s!Agwy_QljRwlGgcoJeZMiimuq3H36Ww=20
> <https://www.google.com/url?q=3Dhttps%3A%2F%2F1drv.ms%2Fb%2Fs!Agwy_QljRwl=
GgcoJeZMiimuq3H36Ww&sa=3DD&sntz=3D1&usg=3DAFQjCNH4Mt71oANAe87AA1PY9Qf74w5yW=
Q>
>
> I have no idea what to do with it now.  If you have any comments on the=
=20
> content, or how to actually proceed, let me know! =3D^-^=3D
>
> Melissa
>

Melissa, the functionality you propose is definitely useful. However, it=20
looks to me that it is already contained in the contracts proposal:=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html

Under the contract proposal, anywhere where the statement is expected, you=
=20
can type:

[[assert: false]];

Which is somewhat similar to old macro assert(), but is not a macro anymore=
=20
and is allowed to be a hint for optimizations and warning generation, and=
=20
additionally is allowed to be static-analysis-tested for correctness.

If contracts get accepted [[unreachable]] will become redundant. However=20
contracts are a big and novel feature, which makes it likely for them to=20
miss the place in C++20. Your proposal is small, so it has bigger chances=
=20
of succeeding.

Anyway, it would be fair to put a comparison with contracts in your=20
proposal.

Good luck.
&rzej; =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/74928e4c-8f1e-4036-93d8-2560c27b651d%40isocpp.or=
g.

------=_Part_1112_45239803.1489147477558
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu czwartek, 9 marca 2017 04:49:35 UTC+1 u=C5=
=BCytkownik Myriachan 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">I wrote up a proposal document for a new attribute, =
[[unreachable]], which lets you mark locations in code as being unreachable=
 for optimization purposes, or to suppress certain warnings.<br><br>This ha=
s been discussed on the mailing list before; there&#39;s a link to that thr=
ead in the .pdf.<br><br><a href=3D"https://www.google.com/url?q=3Dhttps%3A%=
2F%2F1drv.ms%2Fb%2Fs!Agwy_QljRwlGgcoJeZMiimuq3H36Ww&amp;sa=3DD&amp;sntz=3D1=
&amp;usg=3DAFQjCNH4Mt71oANAe87AA1PY9Qf74w5yWQ" target=3D"_blank" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttp=
s%3A%2F%2F1drv.ms%2Fb%2Fs!Agwy_QljRwlGgcoJeZMiimuq3H36Ww\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNH4Mt71oANAe87AA1PY9Qf74w5yWQ&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2F1drv.m=
s%2Fb%2Fs!Agwy_QljRwlGgcoJeZMiimuq3H36Ww\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNH4Mt71oANAe87AA1PY9Qf74w5yWQ&#39;;return true;">https://1drv.ms/b/s!A=
gwy_<wbr>QljRwlGgcoJeZMiimuq3H36Ww</a><br><br>I have no idea what to do wit=
h it now.=C2=A0 If you have any comments on the content, or how to actually=
 proceed, let me know! =3D^-^=3D<br><br>Melissa<br></div></blockquote><div>=
<br>Melissa, the functionality you propose is definitely useful. However, i=
t looks to me that it is already contained in the contracts proposal: <a hr=
ef=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html"=
>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html</a><b=
r><br>Under the contract proposal, anywhere where the statement is expected=
, you can type:<br><br><div style=3D"background-color: rgb(250, 250, 250); =
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; o=
verflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span style=3D"color: #660;" class=3D"style=
d-by-prettify">[[</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">assert</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">false</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">]];</span></div></co=
de></div><br>Which is somewhat similar to old macro assert(), but is not a =
macro anymore and is allowed to be a hint for optimizations and warning gen=
eration, and additionally is allowed to be static-analysis-tested for corre=
ctness.<br><br>If contracts get accepted [[unreachable]] will become redund=
ant. However contracts are a big and novel feature, which makes it likely f=
or them to miss the place in C++20. Your proposal is small, so it has bigge=
r chances of succeeding.<br><br>Anyway, it would be fair to put a compariso=
n with contracts in your proposal.<br><br>Good luck.<br>&amp;rzej;=C2=A0 <b=
r></div></div>

<p></p>

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

------=_Part_1112_45239803.1489147477558--

------=_Part_1111_41837873.1489147477557--

.

------=_Part_2161_913442477.1489149665587
Content-Type: multipart/alternative;
 boundary="----=_Part_2162_1258772651.1489149665587"

------=_Part_2162_1258772651.1489149665587
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le vendredi 10 mars 2017 13:04:37 UTC+1, Andrzej Krzemie=C5=84ski a =C3=A9c=
rit :
>
>
>
> W dniu czwartek, 9 marca 2017 04:49:35 UTC+1 u=C5=BCytkownik Myriachan na=
pisa=C5=82:
>>
>> I wrote up a proposal document for a new attribute, [[unreachable]],=20
>> which lets you mark locations in code as being unreachable for optimizat=
ion=20
>> purposes, or to suppress certain warnings.
>>
>> This has been discussed on the mailing list before; there's a link to=20
>> that thread in the .pdf.
>>
>> https://1drv.ms/b/s!Agwy_QljRwlGgcoJeZMiimuq3H36Ww=20
>> <https://www.google.com/url?q=3Dhttps%3A%2F%2F1drv.ms%2Fb%2Fs!Agwy_QljRw=
lGgcoJeZMiimuq3H36Ww&sa=3DD&sntz=3D1&usg=3DAFQjCNH4Mt71oANAe87AA1PY9Qf74w5y=
WQ>
>>
>> I have no idea what to do with it now.  If you have any comments on the=
=20
>> content, or how to actually proceed, let me know! =3D^-^=3D
>>
>> Melissa
>>
>
> Melissa, the functionality you propose is definitely useful. However, it=
=20
> looks to me that it is already contained in the contracts proposal:=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html
>
> Under the contract proposal, anywhere where the statement is expected, yo=
u=20
> can type:
>
> [[assert: false]];
>
> Which is somewhat similar to old macro assert(), but is not a macro=20
> anymore and is allowed to be a hint for optimizations and warning=20
> generation, and additionally is allowed to be static-analysis-tested for=
=20
> correctness.
>
> If contracts get accepted [[unreachable]] will become redundant. However=
=20
> contracts are a big and novel feature, which makes it likely for them to=
=20
> miss the place in C++20. Your proposal is small, so it has bigger chances=
=20
> of succeeding.
>
> Anyway, it would be fair to put a comparison with contracts in your=20
> proposal.
>
> Good luck.
> &rzej; =20
>

While [[assert axiom: false]] is probably semantically equivalent to the=20
proposed [[unreachable]], the former doesn't really convey the meaning.

I would be more confortable adding [[unreachable]] to the default branch of=
=20
a switch than the equivalent [[assert axiom: false]].

--=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/cc73faa8-2e33-4314-b50b-cf715b4e7ccf%40isocpp.or=
g.

------=_Part_2162_1258772651.1489149665587
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le vendredi 10 mars 2017 13:04:37 UTC+1, Andrzej Krzemie=
=C5=84ski a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><br><br>W dniu czwartek, 9 marca 2017 04:49:35 UTC+1 u=C5=
=BCytkownik Myriachan 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">I wrote up a proposal document for a new attribute, [[unr=
eachable]], which lets you mark locations in code as being unreachable for =
optimization purposes, or to suppress certain warnings.<br><br>This has bee=
n discussed on the mailing list before; there&#39;s a link to that thread i=
n the .pdf.<br><br><a href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2F=
1drv.ms%2Fb%2Fs!Agwy_QljRwlGgcoJeZMiimuq3H36Ww&amp;sa=3DD&amp;sntz=3D1&amp;=
usg=3DAFQjCNH4Mt71oANAe87AA1PY9Qf74w5yWQ" rel=3D"nofollow" target=3D"_blank=
" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%=
2F%2F1drv.ms%2Fb%2Fs!Agwy_QljRwlGgcoJeZMiimuq3H36Ww\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNH4Mt71oANAe87AA1PY9Qf74w5yWQ&#39;;return true;" onclick=3D=
"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2F1drv.ms%2Fb=
%2Fs!Agwy_QljRwlGgcoJeZMiimuq3H36Ww\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NH4Mt71oANAe87AA1PY9Qf74w5yWQ&#39;;return true;">https://1drv.ms/b/s!Agwy_<=
wbr>QljRwlGgcoJeZMiimuq3H36Ww</a><br><br>I have no idea what to do with it =
now.=C2=A0 If you have any comments on the content, or how to actually proc=
eed, let me know! =3D^-^=3D<br><br>Melissa<br></div></blockquote><div><br>M=
elissa, the functionality you propose is definitely useful. However, it loo=
ks to me that it is already contained in the contracts proposal: <a href=3D=
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html" targ=
et=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.g=
oogle.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdoc=
s%2Fpapers%2F2017%2Fp0542r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEJ=
Nud7AqJtcFj3C6c2OKL6v1ZlmA&#39;;return true;" onclick=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2=
Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0542r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEJNud7AqJtcFj3C6c2OKL6v1ZlmA&#39;;return true;">http://www.open-st=
d.org/jtc1/<wbr>sc22/wg21/docs/papers/2017/<wbr>p0542r0.html</a><br><br>Und=
er the contract proposal, anywhere where the statement is expected, you can=
 type:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:=
rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span styl=
e=3D"color:#660">[[</span><span style=3D"color:#008">assert</span><span sty=
le=3D"color:#660">:</span><span style=3D"color:#000"> </span><span style=3D=
"color:#008">false</span><span style=3D"color:#660">]];</span></div></code>=
</div><br>Which is somewhat similar to old macro assert(), but is not a mac=
ro anymore and is allowed to be a hint for optimizations and warning genera=
tion, and additionally is allowed to be static-analysis-tested for correctn=
ess.<br><br>If contracts get accepted [[unreachable]] will become redundant=
.. However contracts are a big and novel feature, which makes it likely for =
them to miss the place in C++20. Your proposal is small, so it has bigger c=
hances of succeeding.<br><br>Anyway, it would be fair to put a comparison w=
ith contracts in your proposal.<br><br>Good luck.<br>&amp;rzej;=C2=A0 <br><=
/div></div></blockquote><div><br>While <span style=3D"font-family: courier =
new,monospace;">[[assert axiom: false]]</span> is probably semantically equ=
ivalent to the proposed <span style=3D"font-family: courier new,monospace;"=
>[[unreachable]]</span>, the former doesn&#39;t really convey the meaning.<=
br><br>I would be more confortable adding <span style=3D"font-family: couri=
er new,monospace;">[[unreachable]]</span> to the <span style=3D"font-family=
: courier new,monospace;">default</span> branch of a <span style=3D"font-fa=
mily: courier new,monospace;">switch</span> than the equivalent <span style=
=3D"font-family: courier new,monospace;">[[assert axiom: false]]<font face=
=3D"arial,sans-serif">.</font></span><br></div></div>

<p></p>

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

------=_Part_2162_1258772651.1489149665587--

------=_Part_2161_913442477.1489149665587--

.

--001a114e00bef60c56054a61bc40
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm with Andrzej for the recommendation to include a discussion of that
aspect of contracts in your proposal; if you don't, people will ask for it
anyway and it will add an iteration of work to your proposal.

Cheers!

2017-03-10 7:41 GMT-05:00 Morwenn <morwenn29@gmail.com>:

> Le vendredi 10 mars 2017 13:04:37 UTC+1, Andrzej Krzemie=C5=84ski a =C3=
=A9crit :
>>
>>
>>
>> W dniu czwartek, 9 marca 2017 04:49:35 UTC+1 u=C5=BCytkownik Myriachan n=
apisa=C5=82:
>>>
>>> I wrote up a proposal document for a new attribute, [[unreachable]],
>>> which lets you mark locations in code as being unreachable for optimiza=
tion
>>> purposes, or to suppress certain warnings.
>>>
>>> This has been discussed on the mailing list before; there's a link to
>>> that thread in the .pdf.
>>>
>>> https://1drv.ms/b/s!Agwy_QljRwlGgcoJeZMiimuq3H36Ww
>>> <https://www.google.com/url?q=3Dhttps%3A%2F%2F1drv.ms%2Fb%2Fs!Agwy_QljR=
wlGgcoJeZMiimuq3H36Ww&sa=3DD&sntz=3D1&usg=3DAFQjCNH4Mt71oANAe87AA1PY9Qf74w5=
yWQ>
>>>
>>> I have no idea what to do with it now.  If you have any comments on the
>>> content, or how to actually proceed, let me know! =3D^-^=3D
>>>
>>> Melissa
>>>
>>
>> Melissa, the functionality you propose is definitely useful. However, it
>> looks to me that it is already contained in the contracts proposal:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html
>>
>> Under the contract proposal, anywhere where the statement is expected,
>> you can type:
>>
>> [[assert: false]];
>>
>> Which is somewhat similar to old macro assert(), but is not a macro
>> anymore and is allowed to be a hint for optimizations and warning
>> generation, and additionally is allowed to be static-analysis-tested for
>> correctness.
>>
>> If contracts get accepted [[unreachable]] will become redundant. However
>> contracts are a big and novel feature, which makes it likely for them to
>> miss the place in C++20. Your proposal is small, so it has bigger chance=
s
>> of succeeding.
>>
>> Anyway, it would be fair to put a comparison with contracts in your
>> proposal.
>>
>> Good luck.
>> &rzej;
>>
>
> While [[assert axiom: false]] is probably semantically equivalent to the
> proposed [[unreachable]], the former doesn't really convey the meaning.
>
> I would be more confortable adding [[unreachable]] to the default branch
> of a switch than the equivalent [[assert axiom: false]].
>
> --
> 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/cc73faa8-2e33-4314-
> b50b-cf715b4e7ccf%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc73faa8-2e=
33-4314-b50b-cf715b4e7ccf%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAKiZDp13zBrzEFnFh9n%3DT7c6DmkGFrX%2BowM%3DOQGaG=
H3KoJOUxw%40mail.gmail.com.

--001a114e00bef60c56054a61bc40
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;m with Andrzej for the recommendation to includ=
e a discussion of that aspect of contracts in your proposal; if you don&#39=
;t, people will ask for it anyway and it will add an iteration of work to y=
our proposal.<br><br></div>Cheers!<br></div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">2017-03-10 7:41 GMT-05:00 Morwenn <span dir=3D"l=
tr">&lt;<a href=3D"mailto:morwenn29@gmail.com" target=3D"_blank">morwenn29@=
gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><span class=3D"">Le vendredi 10 mars 2017 13:04:37 UTC+1, Andrzej Krzemie=
=C5=84ski a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><br><br>W dniu czwartek, 9 marca 2017 04:49:35 UTC+1 u=C5=BCytko=
wnik Myriachan napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">I wrote up a proposal document for a new attribute, [[unreachable=
]], which lets you mark locations in code as being unreachable for optimiza=
tion purposes, or to suppress certain warnings.<br><br>This has been discus=
sed on the mailing list before; there&#39;s a link to that thread in the .p=
df.<br><br><a href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2F1drv.ms%=
2Fb%2Fs!Agwy_QljRwlGgcoJeZMiimuq3H36Ww&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAF=
QjCNH4Mt71oANAe87AA1PY9Qf74w5yWQ" rel=3D"nofollow" target=3D"_blank">https:=
//1drv.ms/b/s!Agwy_QljRw<wbr>lGgcoJeZMiimuq3H36Ww</a><br><br>I have no idea=
 what to do with it now.=C2=A0 If you have any comments on the content, or =
how to actually proceed, let me know! =3D^-^=3D<br><br>Melissa<br></div></b=
lockquote><div><br>Melissa, the functionality you propose is definitely use=
ful. However, it looks to me that it is already contained in the contracts =
proposal: <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
7/p0542r0.html" rel=3D"nofollow" target=3D"_blank">http://www.open-std.org/=
jtc1/s<wbr>c22/wg21/docs/papers/2017/p054<wbr>2r0.html</a><br><br>Under the=
 contract proposal, anywhere where the statement is expected, you can type:=
<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px"><code><div><span style=3D"c=
olor:#660">[[</span><span style=3D"color:#008">assert</span><span style=3D"=
color:#660">:</span><span style=3D"color:#000"> </span><span style=3D"color=
:#008">false</span><span style=3D"color:#660">]];</span></div></code></div>=
<br>Which is somewhat similar to old macro assert(), but is not a macro any=
more and is allowed to be a hint for optimizations and warning generation, =
and additionally is allowed to be static-analysis-tested for correctness.<b=
r><br>If contracts get accepted [[unreachable]] will become redundant. Howe=
ver contracts are a big and novel feature, which makes it likely for them t=
o miss the place in C++20. Your proposal is small, so it has bigger chances=
 of succeeding.<br><br>Anyway, it would be fair to put a comparison with co=
ntracts in your proposal.<br><br>Good luck.<br>&amp;rzej;=C2=A0 <br></div><=
/div></blockquote></span><div><br>While <span style=3D"font-family:courier =
new,monospace">[[assert axiom: false]]</span> is probably semantically equi=
valent to the proposed <span style=3D"font-family:courier new,monospace">[[=
unreachable]]</span>, the former doesn&#39;t really convey the meaning.<br>=
<br>I would be more confortable adding <span style=3D"font-family:courier n=
ew,monospace">[[unreachable]]</span> to the <span style=3D"font-family:cour=
ier new,monospace">default</span> branch of a <span style=3D"font-family:co=
urier new,monospace">switch</span> than the equivalent <span style=3D"font-=
family:courier new,monospace">[[assert axiom: false]]<font face=3D"arial,sa=
ns-serif">.</font></span><br></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cc73faa8-2e33-4314-b50b-cf715b4e7ccf%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/cc73=
faa8-2e33-4314-<wbr>b50b-cf715b4e7ccf%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp13zBrzEFnFh9n%3DT7c6DmkGFrX%2B=
owM%3DOQGaGH3KoJOUxw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp13zB=
rzEFnFh9n%3DT7c6DmkGFrX%2BowM%3DOQGaGH3KoJOUxw%40mail.gmail.com</a>.<br />

--001a114e00bef60c56054a61bc40--

.

------=_Part_2563_1377689398.1489242275045
Content-Type: multipart/alternative;
 boundary="----=_Part_2564_494395188.1489242275045"

------=_Part_2564_494395188.1489242275045
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu pi=C4=85tek, 10 marca 2017 13:41:05 UTC+1 u=C5=BCytkownik Morwenn na=
pisa=C5=82:
>
> Le vendredi 10 mars 2017 13:04:37 UTC+1, Andrzej Krzemie=C5=84ski a =C3=
=A9crit :
>>
>>
>>
>> W dniu czwartek, 9 marca 2017 04:49:35 UTC+1 u=C5=BCytkownik Myriachan n=
apisa=C5=82:
>>>
>>> I wrote up a proposal document for a new attribute, [[unreachable]],=20
>>> which lets you mark locations in code as being unreachable for optimiza=
tion=20
>>> purposes, or to suppress certain warnings.
>>>
>>> This has been discussed on the mailing list before; there's a link to=
=20
>>> that thread in the .pdf.
>>>
>>> https://1drv.ms/b/s!Agwy_QljRwlGgcoJeZMiimuq3H36Ww=20
>>> <https://www.google.com/url?q=3Dhttps%3A%2F%2F1drv.ms%2Fb%2Fs!Agwy_QljR=
wlGgcoJeZMiimuq3H36Ww&sa=3DD&sntz=3D1&usg=3DAFQjCNH4Mt71oANAe87AA1PY9Qf74w5=
yWQ>
>>>
>>> I have no idea what to do with it now.  If you have any comments on the=
=20
>>> content, or how to actually proceed, let me know! =3D^-^=3D
>>>
>>>
>>> Under the contract proposal, anywhere where the statement is expected,=
=20
>>> you can type:
>>>
>>> [[assert: false]];
>>>
>>> While [[assert axiom: false]] is probably semantically equivalent to=20
>>> the proposed [[unreachable]], the former doesn't really convey the=20
>>> meaning.
>>>
>>> I would be more confortable adding [[unreachable]] to the default=20
>>> branch of a switch than the equivalent [[assert axiom: false]].
>>>
>>
Given that the expression in the assertion is a compile-time constant only=
=20
[[assert: false]] is fine. But the interaction goes beyond only syntax. If=
=20
we have attribute [[unreachable]] maybe we want it to behave like [[assert:=
=20
false]] in every detail; that is: allow calling contract violation handlers=
=20
in test builds, if this place in the code is reached. This way the hint can=
=20
be used not only for optimization, but also for instrumentation.

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/f6b40768-7dbc-4019-b90b-f5c4398f0e25%40isocpp.or=
g.

------=_Part_2564_494395188.1489242275045
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 10 marca 2017 13:41:05 UTC+1 u=
=C5=BCytkownik Morwenn 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">Le vendredi 10 mars 2017 13:04:37 UTC+1, Andrzej Krz=
emie=C5=84ski a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><br><br>W dniu czwartek, 9 marca 2017 04:49:35 UTC+1 u=C5=BC=
ytkownik Myriachan napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v>I wrote up a proposal document for a new attribute, [[unreachable]], whic=
h lets you mark locations in code as being unreachable for optimization pur=
poses, or to suppress certain warnings.<br><br>This has been discussed on t=
he mailing list before; there&#39;s a link to that thread in the .pdf.<br><=
br><a href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2F1drv.ms%2Fb%2Fs!=
Agwy_QljRwlGgcoJeZMiimuq3H36Ww&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNH4Mt=
71oANAe87AA1PY9Qf74w5yWQ" rel=3D"nofollow" target=3D"_blank" onmousedown=3D=
"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2F1drv.ms%2Fb=
%2Fs!Agwy_QljRwlGgcoJeZMiimuq3H36Ww\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NH4Mt71oANAe87AA1PY9Qf74w5yWQ&#39;;return true;" onclick=3D"this.href=3D&#3=
9;https://www.google.com/url?q\x3dhttps%3A%2F%2F1drv.ms%2Fb%2Fs!Agwy_QljRwl=
GgcoJeZMiimuq3H36Ww\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH4Mt71oANAe87AA=
1PY9Qf74w5yWQ&#39;;return true;">https://1drv.ms/b/s!Agwy_<wbr>QljRwlGgcoJe=
ZMiimuq3H36Ww</a><br><br>I have no idea what to do with it now.=C2=A0 If yo=
u have any comments on the content, or how to actually proceed, let me know=
! =3D^-^=3D<br><br><br>Under the contract proposal, anywhere where the stat=
ement is expected, you can type:<br><br><div style=3D"background-color:rgb(=
250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:=
1px"><code><div><span style=3D"color:#660">[[</span><span style=3D"color:#0=
08">assert</span><span style=3D"color:#660">:</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#008">false</span><span style=3D"color:#66=
0">]];</span></div></code></div><br>While <span style=3D"font-family:courie=
r new,monospace">[[assert axiom: false]]</span> is probably semantically eq=
uivalent to the proposed <span style=3D"font-family:courier new,monospace">=
[[unreachable]]</span>, the former doesn&#39;t really convey the meaning.<b=
r><br>I would be more confortable adding <span style=3D"font-family:courier=
 new,monospace">[[unreachable]]</span> to the <span style=3D"font-family:co=
urier new,monospace">default</span> branch of a <span style=3D"font-family:=
courier new,monospace">switch</span> than the equivalent <span style=3D"fon=
t-family:courier new,monospace">[[assert axiom: false]]<font face=3D"arial,=
sans-serif">.</font></span></div></blockquote></div></blockquote></div></bl=
ockquote><div><br>Given that the expression in the assertion is a compile-t=
ime constant only [[assert: false]] is fine. But the interaction goes beyon=
d only syntax. If we have attribute [[unreachable]] maybe we want it to beh=
ave like [[assert: false]] in every detail; that is: allow calling contract=
 violation handlers in test builds, if this place in the code is reached. T=
his way the hint can be used not only for optimization, but also for instru=
mentation.<br><br>Regards,<br>&amp;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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f6b40768-7dbc-4019-b90b-f5c4398f0e25%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f6b40768-7dbc-4019-b90b-f5c4398f0e25=
%40isocpp.org</a>.<br />

------=_Part_2564_494395188.1489242275045--

------=_Part_2563_1377689398.1489242275045--

.

------=_Part_1670_1281867276.1489324755479
Content-Type: multipart/alternative;
 boundary="----=_Part_1671_340757506.1489324755479"

------=_Part_1671_340757506.1489324755479
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think the opposite is correct WRT tooling; if you have a separate=20
[[unreachable]] attribute, not only does it convey the intention better to=
=20
the reader, but it also does to any tool which sees the attribute, so for=
=20
example a static analyzer can show exactly the path in which=20
[[unreachable]] code becomes reachable, but not necessarily show it for=20
failing [[assert]] attributes.

Cheers,
Dan


On Saturday, March 11, 2017 at 4:24:35 PM UTC+2, Andrzej Krzemie=C5=84ski w=
rote:
>
>
>
> W dniu pi=C4=85tek, 10 marca 2017 13:41:05 UTC+1 u=C5=BCytkownik Morwenn =
napisa=C5=82:
>>
>> Le vendredi 10 mars 2017 13:04:37 UTC+1, Andrzej Krzemie=C5=84ski a =C3=
=A9crit :
>>>
>>>
>>>
>>> W dniu czwartek, 9 marca 2017 04:49:35 UTC+1 u=C5=BCytkownik Myriachan=
=20
>>> napisa=C5=82:
>>>>
>>>> I wrote up a proposal document for a new attribute, [[unreachable]],=
=20
>>>> which lets you mark locations in code as being unreachable for optimiz=
ation=20
>>>> purposes, or to suppress certain warnings.
>>>>
>>>> This has been discussed on the mailing list before; there's a link to=
=20
>>>> that thread in the .pdf.
>>>>
>>>> https://1drv.ms/b/s!Agwy_QljRwlGgcoJeZMiimuq3H36Ww=20
>>>> <https://www.google.com/url?q=3Dhttps%3A%2F%2F1drv.ms%2Fb%2Fs!Agwy_Qlj=
RwlGgcoJeZMiimuq3H36Ww&sa=3DD&sntz=3D1&usg=3DAFQjCNH4Mt71oANAe87AA1PY9Qf74w=
5yWQ>
>>>>
>>>> I have no idea what to do with it now.  If you have any comments on th=
e=20
>>>> content, or how to actually proceed, let me know! =3D^-^=3D
>>>>
>>>>
>>>> Under the contract proposal, anywhere where the statement is expected,=
=20
>>>> you can type:
>>>>
>>>> [[assert: false]];
>>>>
>>>> While [[assert axiom: false]] is probably semantically equivalent to=
=20
>>>> the proposed [[unreachable]], the former doesn't really convey the=20
>>>> meaning.
>>>>
>>>> I would be more confortable adding [[unreachable]] to the default=20
>>>> branch of a switch than the equivalent [[assert axiom: false]].
>>>>
>>>
> Given that the expression in the assertion is a compile-time constant onl=
y=20
> [[assert: false]] is fine. But the interaction goes beyond only syntax. I=
f=20
> we have attribute [[unreachable]] maybe we want it to behave like [[asser=
t:=20
> false]] in every detail; that is: allow calling contract violation handle=
rs=20
> in test builds, if this place in the code is reached. This way the hint c=
an=20
> be used not only for optimization, but also for instrumentation.
>
> 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/996e889d-5922-4e13-84dd-d914ec44f5a4%40isocpp.or=
g.

------=_Part_1671_340757506.1489324755479
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think the opposite is correct WRT tooling; if you have a=
 separate [[unreachable]] attribute, not only does it convey the intention =
better to the reader, but it also does to any tool which sees the attribute=
, so for example a static analyzer can show exactly the path in which [[unr=
eachable]] code becomes reachable, but not necessarily show it for failing =
[[assert]] attributes.<br><br>Cheers,<div>Dan<br><div><br><br>On Saturday, =
March 11, 2017 at 4:24:35 PM UTC+2, Andrzej Krzemie=C5=84ski wrote:<blockqu=
ote 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 pi=C4=
=85tek, 10 marca 2017 13:41:05 UTC+1 u=C5=BCytkownik Morwenn 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">Le vendredi 10 mars=
 2017 13:04:37 UTC+1, Andrzej Krzemie=C5=84ski a =C3=A9crit=C2=A0:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>W dniu czwartek, 9 =
marca 2017 04:49:35 UTC+1 u=C5=BCytkownik Myriachan napisa=C5=82:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div>I wrote up a proposal document for a new=
 attribute, [[unreachable]], which lets you mark locations in code as being=
 unreachable for optimization purposes, or to suppress certain warnings.<br=
><br>This has been discussed on the mailing list before; there&#39;s a link=
 to that thread in the .pdf.<br><br><a href=3D"https://www.google.com/url?q=
=3Dhttps%3A%2F%2F1drv.ms%2Fb%2Fs!Agwy_QljRwlGgcoJeZMiimuq3H36Ww&amp;sa=3DD&=
amp;sntz=3D1&amp;usg=3DAFQjCNH4Mt71oANAe87AA1PY9Qf74w5yWQ" rel=3D"nofollow"=
 target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://www.google.com/u=
rl?q\x3dhttps%3A%2F%2F1drv.ms%2Fb%2Fs!Agwy_QljRwlGgcoJeZMiimuq3H36Ww\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH4Mt71oANAe87AA1PY9Qf74w5yWQ&#39;;return =
true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A=
%2F%2F1drv.ms%2Fb%2Fs!Agwy_QljRwlGgcoJeZMiimuq3H36Ww\x26sa\x3dD\x26sntz\x3d=
1\x26usg\x3dAFQjCNH4Mt71oANAe87AA1PY9Qf74w5yWQ&#39;;return true;">https://1=
drv.ms/b/s!Agwy_<wbr>QljRwlGgcoJeZMiimuq3H36Ww</a><br><br>I have no idea wh=
at to do with it now.=C2=A0 If you have any comments on the content, or how=
 to actually proceed, let me know! =3D^-^=3D<br><br><br>Under the contract =
proposal, anywhere where the statement is expected, you can type:<br><br><d=
iv style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187)=
;border-style:solid;border-width:1px"><code><div><span style=3D"color:#660"=
>[[</span><span style=3D"color:#008">assert</span><span style=3D"color:#660=
">:</span><span style=3D"color:#000"> </span><span style=3D"color:#008">fal=
se</span><span style=3D"color:#660">]];</span></div></code></div><br>While =
<span style=3D"font-family:courier new,monospace">[[assert axiom: false]]</=
span> is probably semantically equivalent to the proposed <span style=3D"fo=
nt-family:courier new,monospace">[[unreachable]]</span>, the former doesn&#=
39;t really convey the meaning.<br><br>I would be more confortable adding <=
span style=3D"font-family:courier new,monospace">[[unreachable]]</span> to =
the <span style=3D"font-family:courier new,monospace">default</span> branch=
 of a <span style=3D"font-family:courier new,monospace">switch</span> than =
the equivalent <span style=3D"font-family:courier new,monospace">[[assert a=
xiom: false]]<font face=3D"arial,sans-serif">.</font></span></div></blockqu=
ote></div></blockquote></div></blockquote><div><br>Given that the expressio=
n in the assertion is a compile-time constant only [[assert: false]] is fin=
e. But the interaction goes beyond only syntax. If we have attribute [[unre=
achable]] maybe we want it to behave like [[assert: false]] in every detail=
; that is: allow calling contract violation handlers in test builds, if thi=
s place in the code is reached. This way the hint can be used not only for =
optimization, but also for instrumentation.<br><br>Regards,<br>&amp;rzej;<b=
r></div></div></blockquote></div></div></div>

<p></p>

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

------=_Part_1671_340757506.1489324755479--

------=_Part_1670_1281867276.1489324755479--

.

------=_Part_9466_2146887185.1489436908096
Content-Type: multipart/alternative;
 boundary="----=_Part_9467_961850427.1489436908096"

------=_Part_9467_961850427.1489436908096
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sunday, March 12, 2017 at 6:19:15 AM UTC-7, d...@soundradix.com wrote:
>
> I think the opposite is correct WRT tooling; if you have a separate=20
> [[unreachable]] attribute, not only does it convey the intention better t=
o=20
> the reader, but it also does to any tool which sees the attribute, so for=
=20
> example a static analyzer can show exactly the path in which=20
> [[unreachable]] code becomes reachable, but not necessarily show it for=
=20
> failing [[assert]] attributes.
>
> On Saturday, March 11, 2017 at 4:24:35 PM UTC+2, Andrzej Krzemie=C5=84ski=
 wrote:
>>
>>
>> Given that the expression in the assertion is a compile-time constant=20
>> only [[assert: false]] is fine. But the interaction goes beyond only=20
>> syntax. If we have attribute [[unreachable]] maybe we want it to behave=
=20
>> like [[assert: false]] in every detail; that is: allow calling contract=
=20
>> violation handlers in test builds, if this place in the code is reached.=
=20
>> This way the hint can be used not only for optimization, but also for=20
>> instrumentation.
>>
>>

 I noticed that the draft of contractual programming does not say that=20
behavior is undefined if the expression is false past an [[assert axiom]]. =
=20
I asked co-author Professor J. Daniel Garcia about why the Standardese=20
didn't say that the behavior is undefined, and his reply was:

Because that is not necessarily true. It is just that the assertion is not=
=20
> checked.


This to me gives [[unreachable]] a niche of its own, rather than merely=20
being a simpler subset of another proposal.

Melissa

--=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/51fa0491-97aa-48c8-b361-353f5ecc7a0f%40isocpp.or=
g.

------=_Part_9467_961850427.1489436908096
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, March 12, 2017 at 6:19:15 AM UTC-7, d...@soundr=
adix.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">I think the opposite is correct WRT tooling; if you have a separate [[unr=
eachable]] attribute, not only does it convey the intention better to the r=
eader, but it also does to any tool which sees the attribute, so for exampl=
e a static analyzer can show exactly the path in which [[unreachable]] code=
 becomes reachable, but not necessarily show it for failing [[assert]] attr=
ibutes.<br><div><div><br>On Saturday, March 11, 2017 at 4:24:35 PM UTC+2, A=
ndrzej Krzemie=C5=84ski wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><br><div>Given that the expression in the assertion is a compil=
e-time constant only [[assert: false]] is fine. But the interaction goes be=
yond only syntax. If we have attribute [[unreachable]] maybe we want it to =
behave like [[assert: false]] in every detail; that is: allow calling contr=
act violation handlers in test builds, if this place in the code is reached=
.. This way the hint can be used not only for optimization, but also for ins=
trumentation.<br><br></div></div></blockquote></div></div></div></blockquot=
e><div><br><br>=C2=A0I noticed that the draft of contractual programming do=
es not say that behavior is undefined if the expression is false past an [[=
assert axiom]].=C2=A0 I asked co-author Professor J. Daniel Garcia about wh=
y the Standardese didn&#39;t say that the behavior is undefined, and his re=
ply was:<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">B=
ecause that is not necessarily true. It is just that the assertion is not c=
hecked.</blockquote><div><br>This to me gives [[unreachable]] a niche of it=
s own, rather than merely being a simpler subset of another proposal.<br><b=
r>Melissa<br></div></div></div>

<p></p>

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

------=_Part_9467_961850427.1489436908096--

------=_Part_9466_2146887185.1489436908096--

.

--94eb2c1b2a0ca23aee054aa43289
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2017-03-13 21:28 GMT+01:00 Myriachan <myriachan@gmail.com>:

> On Sunday, March 12, 2017 at 6:19:15 AM UTC-7, d...@soundradix.com wrote:
>>
>> I think the opposite is correct WRT tooling; if you have a separate
>> [[unreachable]] attribute, not only does it convey the intention better =
to
>> the reader, but it also does to any tool which sees the attribute, so fo=
r
>> example a static analyzer can show exactly the path in which
>> [[unreachable]] code becomes reachable, but not necessarily show it for
>> failing [[assert]] attributes.
>>
>> On Saturday, March 11, 2017 at 4:24:35 PM UTC+2, Andrzej Krzemie=C5=84sk=
i
>> wrote:
>>>
>>>
>>> Given that the expression in the assertion is a compile-time constant
>>> only [[assert: false]] is fine. But the interaction goes beyond only
>>> syntax. If we have attribute [[unreachable]] maybe we want it to behave
>>> like [[assert: false]] in every detail; that is: allow calling contract
>>> violation handlers in test builds, if this place in the code is reached=
..
>>> This way the hint can be used not only for optimization, but also for
>>> instrumentation.
>>>
>>>
>
>  I noticed that the draft of contractual programming does not say that
> behavior is undefined if the expression is false past an [[assert axiom]]=
..
> I asked co-author Professor J. Daniel Garcia about why the Standardese
> didn't say that the behavior is undefined, and his reply was:
>
> Because that is not necessarily true. It is just that the assertion is no=
t
>> checked.
>
>
I think that this word "axiom" in emails only complicates the
communication. It is sufficient to focus on [[assert: false]]. I understand
that your objective is to give the compiler a hint in order to enable
certain optimizations. Indeed, in the proposal, they do not mention it. If
this is intentional, then the contract proposal has missed an important
goal. This needs to be brought up to the attention of te authors and the
committee.


>
> This to me gives [[unreachable]] a niche of its own, rather than merely
> being a simpler subset of another proposal.
>

I still hope there is a misunderstanding as to what contracts are supposed
to do. But whatever the case, your proposal has two important advantages:
* it is useful in practice.
* it has been implemented (and tested)

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/CAOenAXjwx8h4SVjMavFxZr-N2byoUuw7QrCKr7gr-9Np_pU=
Xwg%40mail.gmail.com.

--94eb2c1b2a0ca23aee054aa43289
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2017-03-13 21:28 GMT+01:00 Myriachan <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>&gt;</s=
pan>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">O=
n Sunday, March 12, 2017 at 6:19:15 AM UTC-7, <a href=3D"mailto:d...@soundr=
adix.com" target=3D"_blank">d...@soundradix.com</a> wrote:</span><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">I think the=
 opposite is correct WRT tooling; if you have a separate [[unreachable]] at=
tribute, not only does it convey the intention better to the reader, but it=
 also does to any tool which sees the attribute, so for example a static an=
alyzer can show exactly the path in which [[unreachable]] code becomes reac=
hable, but not necessarily show it for failing [[assert]] attributes.<br></=
span><div><div><br><span class=3D"">On Saturday, March 11, 2017 at 4:24:35 =
PM UTC+2, Andrzej Krzemie=C5=84ski wrote:</span><span class=3D""><blockquot=
e 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><div>Given that the expr=
ession in the assertion is a compile-time constant only [[assert: false]] i=
s fine. But the interaction goes beyond only syntax. If we have attribute [=
[unreachable]] maybe we want it to behave like [[assert: false]] in every d=
etail; that is: allow calling contract violation handlers in test builds, i=
f this place in the code is reached. This way the hint can be used not only=
 for optimization, but also for instrumentation.<br><br></div></div></block=
quote></span></div></div></div></blockquote><div><br><br>=C2=A0I noticed th=
at the draft of contractual programming does not say that behavior is undef=
ined if the expression is false past an [[assert axiom]].=C2=A0 I asked co-=
author Professor J. Daniel Garcia about why the Standardese didn&#39;t say =
that the behavior is undefined, and his reply was:<br><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Because that is not necessarily true. It i=
s just that the assertion is not checked.</blockquote></div></div></blockqu=
ote><div><br></div><div>I think that this word &quot;axiom&quot; in emails =
only complicates the communication. It is sufficient to focus on [[assert: =
false]]. I understand that your objective is to give the compiler a hint in=
 order to enable certain optimizations. Indeed, in the proposal, they do no=
t mention it. If this is intentional, then the contract proposal has missed=
 an important goal. This needs to be brought up to the attention of te auth=
ors and the committee.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><div><br>This to me gives [[unreachable]] a niche of it=
s own, rather than merely being a simpler subset of another proposal.<br></=
div></div></div></blockquote><div><br></div><div>I still hope there is a mi=
sunderstanding as to what contracts are supposed to do. But whatever the ca=
se, your proposal has two important advantages:<br></div><div>* it is usefu=
l in practice.<br></div><div>* it has been implemented (and tested)<br><br>=
</div><div>Regards,<br></div><div>&amp;rzej;<br></div><div>=C2=A0<br></div>=
</div></div></div>

<p></p>

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

--94eb2c1b2a0ca23aee054aa43289--

.

Em segunda-feira, 13 de mar=C3=A7o de 2017, =C3=A0s 13:28:28 PDT, Myriachan=
 escreveu:
>  I noticed that the draft of contractual programming does not say that
> behavior is undefined if the expression is false past an [[assert axiom]]=
..
> I asked co-author Professor J. Daniel Garcia about why the Standardese
> didn't say that the behavior is undefined, and his reply was:
>=20
> > Because that is not necessarily true. It is just that the assertion is =
not
> > checked.

I'm not sure I understand the answer. Let's say I have this in my code:

 [[assert: q.is_valid()]];

According to the answer, the assertion is something that the compiler need =
not=20
check anymore in the future, because I asserted that it is true. So what if=
 I=20
have later in the code path (possibly in an inlined function)

 if (q.is_valid())
  return q.pop();

How will the compiler react? If it deletes the check because I asserted its=
=20
result, it will call q.pop(), which may lead to a crash.

Isn't that the definition of UB?

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/1607497.4jKLvpMD02%40tjmaciei-mobl1.

.

Em sexta-feira, 10 de mar=C3=A7o de 2017, =C3=A0s 04:04:37 PDT, Andrzej Krz=
emie=C5=84ski=20
escreveu:
> Under the contract proposal, anywhere where the statement is expected, yo=
u
> can type:
>=20
> [[assert: false]];
>=20
> Which is somewhat similar to old macro assert(), but is not a macro anymo=
re
> and is allowed to be a hint for optimizations and warning generation, and
> additionally is allowed to be static-analysis-tested for correctness.
>=20
> If contracts get accepted [[unreachable]] will become redundant. However
> contracts are a big and novel feature, which makes it likely for them to
> miss the place in C++20. Your proposal is small, so it has bigger chances
> of succeeding.

Here's some feedback on real use:

1) Qt has Q_UNREACHABLE(), a macro that expands in release mode with GCC an=
d=20
Clang to:
 __builtin_unreachable()
and with MSVC to:
 __assume(false);

Both things tell the compilers that this is unreachable and they can delete=
=20
all code paths leading to it, as it can never happen.

Additionally, in debug mode, the macro expands to a [[noreturn]] call to=20
qFatal("Unreachable was reached").

2) Qt has Q_ASSUME(expr), a macro that tells the compiler to assert that a=
=20
given expression is true. It expands with MSVC to:
 __assume(expr)
and with Clang and GCC to:
 if (!!(expr)); else __builtin_unreachable()
(inverted condition so it can be used as statement of an if]

This means the optimiser can delete code that would violate that assertion.=
=20
This macro is not different in debug or release mode, we just want to ask t=
he=20
compiler for better code. But in our experience, the optimisers are not (ye=
t)=20
smart enough to take advantage of this hint. Moreover, GCC and Clang=20
frequently introduce the code for the "if", even if one of the sides falls =
of=20
a cliff, so they pessimise the code instead.

3) Qt's Q_ASSERT(expr) was supposed to "decay" to Q_ASSUME in release mode.=
=20
That way, the compiler could delete code paths that would violate the=20
assertion. However, given the pessimisation I mentioned above, we couldn't =
do=20
this.

I've used this technique in other, controlled conditions.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/1704715.8OGLLQAB3T%40tjmaciei-mobl1.

.

------=_Part_3582_559116313.1489449450486
Content-Type: multipart/alternative;
 boundary="----=_Part_3583_236828868.1489449450486"

------=_Part_3583_236828868.1489449450486
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 14 marca 2017 00:23:57 UTC+1 u=C5=BCytkownik Thiago Macieira=
=20
napisa=C5=82:
>
> Em segunda-feira, 13 de mar=C3=A7o de 2017, =C3=A0s 13:28:28 PDT, Myriach=
an=20
> escreveu:=20
> >  I noticed that the draft of contractual programming does not say that=
=20
> > behavior is undefined if the expression is false past an [[assert=20
> axiom]].=20
> > I asked co-author Professor J. Daniel Garcia about why the Standardese=
=20
> > didn't say that the behavior is undefined, and his reply was:=20
> >=20
> > > Because that is not necessarily true. It is just that the assertion i=
s=20
> not=20
> > > checked.=20
>
> I'm not sure I understand the answer. Let's say I have this in my code:=
=20
>
>         [[assert: q.is_valid()]];=20
>
> According to the answer, the assertion is something that the compiler nee=
d=20
> not=20
> check anymore in the future, because I asserted that it is true. So what=
=20
> if I=20
> have later in the code path (possibly in an inlined function)=20
>
>         if (q.is_valid())=20
>                 return q.pop();=20
>
> How will the compiler react? If it deletes the check because I asserted=
=20
> its=20
> result, it will call q.pop(), which may lead to a crash.=20
>
> Isn't that the definition of UB?=20
>
>
I think what Daniel is saying is this. If you have a function like this:

void f(Q& q1, Q& q2)
{
    [[assert: q1.is_valid()]]; // (1)
    q1.pop();                  // (2)

    [[assert: q2.is_valid()]]; // (3)
    if (q2.is_valid())         // (4)
       q2.pop();               // (5)
}

assert at (1) can disappear, an invoking (2) could cause an UB. Also,=20
assert at (3) can disappear, but a defensive check at (4) will still be=20
executed because, as Melissa indicated, in the current contracts proposal,=
=20
compiler is not allowed to use the expression in the assertion as a hint=20
for optimizations or for doing any assumptions.

Regards,
&rzej;


=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/715b4536-606e-4396-81c9-24e975a1a857%40isocpp.or=
g.

------=_Part_3583_236828868.1489449450486
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:23:57 UTC+1 u=C5=
=BCytkownik Thiago Macieira napisa=C5=82:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">Em segunda-feira, 13 de mar=C3=A7o de 2017, =C3=A0s 13:28:28 PDT=
, Myriachan escreveu:
<br>&gt; =C2=A0I noticed that the draft of contractual programming does not=
 say that
<br>&gt; behavior is undefined if the expression is false past an [[assert =
axiom]].
<br>&gt; I asked co-author Professor J. Daniel Garcia about why the Standar=
dese
<br>&gt; didn&#39;t say that the behavior is undefined, and his reply was:
<br>&gt;=20
<br>&gt; &gt; Because that is not necessarily true. It is just that the ass=
ertion is not
<br>&gt; &gt; checked.
<br>
<br>I&#39;m not sure I understand the answer. Let&#39;s say I have this in =
my code:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[[assert: q.is_valid()]=
];
<br>
<br>According to the answer, the assertion is something that the compiler n=
eed not=20
<br>check anymore in the future, because I asserted that it is true. So wha=
t if I=20
<br>have later in the code path (possibly in an inlined function)
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (q.is_valid())
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0return q.pop();
<br>
<br>How will the compiler react? If it deletes the check because I asserted=
 its=20
<br>result, it will call q.pop(), which may lead to a crash.
<br>
<br>Isn&#39;t that the definition of UB?
<br>
<br></blockquote><div><br>I think what Daniel is saying is this. If you hav=
e a function like this:<br><br><div style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>Q</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> q1</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> Q</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> q2</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">[[</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">assert</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> q1</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">is_valid</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()]];</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// (1)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 q1</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">pop</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// (=
2)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">[[</span><span style=3D"color: #008;" class=3D"styled-by-prettify">asse=
rt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> q2</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">is_valid</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">()]];</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// (3)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">q2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">is_valid</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">())</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// (4)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0q2</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">pop</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">// (5)</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">}</span></div></code></div><br>assert at (1) c=
an disappear, an invoking (2) could cause an UB. Also, assert at (3) can di=
sappear, but a defensive check at (4) will still be executed because, as Me=
lissa indicated, in the current contracts proposal, compiler is not allowed=
 to use the expression in the assertion as a hint for optimizations or for =
doing any assumptions.<br><br>Regards,<br>&amp;rzej;<br><br><br>=C2=A0<br><=
/div></div>

<p></p>

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

------=_Part_3583_236828868.1489449450486--

------=_Part_3582_559116313.1489449450486--

.

------=_Part_163_50466613.1490945126730
Content-Type: multipart/alternative;
 boundary="----=_Part_164_570463809.1490945126731"

------=_Part_164_570463809.1490945126731
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu poniedzia=C5=82ek, 13 marca 2017 21:28:28 UTC+1 u=C5=BCytkownik Myri=
achan=20
napisa=C5=82:
>
>
>  I noticed that the draft of contractual programming does not say that=20
> behavior is undefined if the expression is false past an [[assert axiom]]=
.. =20
> I asked co-author Professor J. Daniel Garcia about why the Standardese=20
> didn't say that the behavior is undefined, and his reply was:
>
> Because that is not necessarily true. It is just that the assertion is no=
t=20
>> checked.
>
>
> This to me gives [[unreachable]] a niche of its own, rather than merely=
=20
> being a simpler subset of another proposal.
>
> Melissa
>

Indeed. The contracts proposal disallows contract-based optimizations.=20
Maybe this is by omission, but trying to figure it out by directly asking=
=20
people, some of which participate in the meetings=20
(https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cM_Rdi1I1bI/d=
iscussion),=20
also suggests that contract-based optimizations may not be supported. If=20
this should be the case, your proposal may become even more important,=20
because it allows building performance-oriented contracts:

#define X_ASSERT(cond) if (cond) {} else { [[unreachable]]; }

Now code like the following can (at least theoretically) be optimized based=
=20
on asserted expressions:

if (i =3D=3D 0)
  log_error(i);  // this can be optimized away (surprising as it seams)

X_ASSERT(i !=3D 0);

if (i !=3D 0)   // this check can be skipped
  invert(i); // this will be invoked unconditionally

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/87857c1f-8d4e-4b6f-a58f-9ae1acc14b0b%40isocpp.or=
g.

------=_Part_164_570463809.1490945126731
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu poniedzia=C5=82ek, 13 marca 2017 21:28:28 U=
TC+1 u=C5=BCytkownik Myriachan napisa=C5=82:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><br><div>=C2=A0I noticed that the draft of c=
ontractual programming does not say that behavior is undefined if the expre=
ssion is false past an [[assert axiom]].=C2=A0 I asked co-author Professor =
J. Daniel Garcia about why the Standardese didn&#39;t say that the behavior=
 is undefined, and his reply was:<br><br><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">Because that is not necessarily true. It is just that the a=
ssertion is not checked.</blockquote><div><br>This to me gives [[unreachabl=
e]] a niche of its own, rather than merely being a simpler subset of anothe=
r proposal.<br><br>Melissa<br></div></div></div></blockquote><div><br>Indee=
d. The contracts proposal disallows contract-based optimizations. Maybe thi=
s is by omission, but trying to figure it out by directly asking people, so=
me of which participate in the meetings (https://groups.google.com/a/isocpp=
..org/d/topic/std-proposals/cM_Rdi1I1bI/discussion), also suggests that cont=
ract-based optimizations may not be supported. If this should be the case, =
your proposal may become even more important, because it allows building pe=
rformance-oriented contracts:<br><br><div style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">#define</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> X_ASSERT</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">cond</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: #008;" class=3D"styled-by-prettify">if</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">cond</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>else</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">[[</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">unreachable</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">]];</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span></div></code></div><br>Now code like the follow=
ing can (at least theoretically) be optimized based on asserted expressions=
:<br><br><div style=3D"background-color: rgb(250, 250, 250); border-color: =
rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: =
break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">if</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">i </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 log_error</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">i</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
=C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// t=
his can be optimized away (surprising as it seams)</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br>X_ASSERT</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">i </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">!=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</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></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">i </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">!=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=
=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// thi=
s check can be skipped</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0 invert</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span 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"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">// this will be =
invoked unconditionally</span></div></code></div><br>Regards,<br>&amp;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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/87857c1f-8d4e-4b6f-a58f-9ae1acc14b0b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/87857c1f-8d4e-4b6f-a58f-9ae1acc14b0b=
%40isocpp.org</a>.<br />

------=_Part_164_570463809.1490945126731--

------=_Part_163_50466613.1490945126730--

.