Topic: What is the status of Contracts?
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 26 Oct 2015 04:40:18 -0700 (PDT)
Raw View
------=_Part_287_1632465216.1445859618438
Content-Type: multipart/alternative;
boundary="----=_Part_288_2021206769.1445859618438"
------=_Part_288_2021206769.1445859618438
Content-Type: text/plain; charset=UTF-8
Sorry, If I am abusing this list, but could anyone who attended the Kona
meeting describe to the people in the list here, what the agreement about
contracts was?
Regards,
&rzej
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_288_2021206769.1445859618438
Content-Type: text/html; charset=UTF-8
<div dir="ltr">Sorry, If I am abusing this list, but could anyone who attended the Kona meeting describe to the people in the list here, what the agreement about contracts was?<br><br>Regards,<br>&rzej<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_288_2021206769.1445859618438--
------=_Part_287_1632465216.1445859618438--
.
Author: Alisdair Meredith <alisdairm@me.com>
Date: Mon, 26 Oct 2015 09:22:22 -0400
Raw View
--Apple-Mail=_A059782F-87ED-4C2C-8114-6AA7EC2B4711
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
There should be a document in the post-Kona mailing, in around 2 weeks.
Although we believe that we have consensus on a way to make progress, and
hopefully a full proposal for the Jacksonville meeting in February, I don=
=E2=80=99t want
to jinx that by jumping out of step to describe it before that. We have =
=E2=80=98persuaded'
an interested neutral party (i.e., not associated with any of the initial p=
roposers)
to produce the write-up for us, to avoid any accidental bias when describin=
g what
was agreed. When a topic has a wide design space and picking any point in =
that
space proves controversial, this is often the best way to proceed.
AlisdairM
> On Oct 26, 2015, at 7:40 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com=
> wrote:
>=20
> Sorry, If I am abusing this list, but could anyone who attended the Kona =
meeting describe to the people in the list here, what the agreement about c=
ontracts was?
>=20
> Regards,
> &rzej
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_A059782F-87ED-4C2C-8114-6AA7EC2B4711
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"">There should be a =
document in the post-Kona mailing, in around 2 weeks.<div class=3D"">Althou=
gh we believe that we have consensus on a way to make progress, and</div><d=
iv class=3D"">hopefully a full proposal for the Jacksonville meeting in Feb=
ruary, I don=E2=80=99t want</div><div class=3D"">to jinx that by jumping ou=
t of step to describe it before that. We have =E2=80=98persuaded'</di=
v><div class=3D"">an interested neutral party (i.e., not associated with an=
y of the initial proposers)</div><div class=3D"">to produce the write-up fo=
r us, to avoid any accidental bias when describing what</div><div class=3D"=
">was agreed. When a topic has a wide design space and picking any po=
int in that</div><div class=3D"">space proves controversial, this is often =
the best way to proceed.</div><div class=3D""><br class=3D""></div><div cla=
ss=3D"">AlisdairM</div><div class=3D""><br class=3D""></div><div class=3D""=
><div><blockquote type=3D"cite" class=3D""><div class=3D"">On Oct 26, 2015,=
at 7:40 AM, Andrzej Krzemie=C5=84ski <<a href=3D"mailto:akrzemi1@gmail.=
com" class=3D"">akrzemi1@gmail.com</a>> wrote:</div><br class=3D"Apple-i=
nterchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">Sorry, If I=
am abusing this list, but could anyone who attended the Kona meeting descr=
ibe to the people in the list here, what the agreement about contracts was?=
<br class=3D""><br class=3D"">Regards,<br class=3D"">&rzej<br class=3D"=
"></div><div class=3D""><br class=3D"webkit-block-placeholder"></div>
-- <br class=3D"">
<br class=3D"">
--- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
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" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" class=3D"">http://groups.google.com/a/isocpp.org/group/std-=
proposals/</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_A059782F-87ED-4C2C-8114-6AA7EC2B4711--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 27 Oct 2015 13:27:48 -0700
Raw View
--001a11c30caa4a87d705231be9de
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Oct 26, 2015 at 6:22 AM, Alisdair Meredith <alisdairm@me.com> wrote=
:
> There should be a document in the post-Kona mailing, in around 2 weeks.
> Although we believe that we have consensus on a way to make progress, and
> hopefully a full proposal for the Jacksonville meeting in February, I
> don=E2=80=99t want
> to jinx that by jumping out of step to describe it before that. We have
> =E2=80=98persuaded'
> an interested neutral party (i.e., not associated with any of the initial
> proposers)
> to produce the write-up for us, to avoid any accidental bias when
> describing what
> was agreed. When a topic has a wide design space and picking any point i=
n
> that
> space proves controversial, this is often the best way to proceed.
>
Without going into the details but to make things slightly less vague, one
topic that we had consensus on was a way to allow a registered precondition
violation handler to throw an exception with semantics that would be
satisfactory for those who were involved in both sides of the discussion,
and in a way that is also consistent with noexcept. In other words, the
approach allows you to have a preconditions on both noexcept and
non-noexcept functions, and you are allowed to register a precondition
handler that throws rather than terminates. IIRC, we didn't yet get to a
point where we had consensus around supporting handlers that can return
(i.e. precondition violation handlers that neither terminate nor throw),
but the progress that was made was still an important step forward.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c30caa4a87d705231be9de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Oct 26, 2015 at 6:22 AM, Alisdair Meredith <span dir=3D"ltr"><<a hre=
f=3D"mailto:alisdairm@me.com" target=3D"_blank">alisdairm@me.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break=
-word">There should be a document in the post-Kona mailing, in around 2 wee=
ks.<div>Although we believe that we have consensus on a way to make progres=
s, and</div><div>hopefully a full proposal for the Jacksonville meeting in =
February, I don=E2=80=99t want</div><div>to jinx that by jumping out of ste=
p to describe it before that.=C2=A0 We have =E2=80=98persuaded'</div><d=
iv>an interested neutral party (i.e., not associated with any of the initia=
l proposers)</div><div>to produce the write-up for us, to avoid any acciden=
tal bias when describing what</div><div>was agreed.=C2=A0 When a topic has =
a wide design space and picking any point in that</div><div>space proves co=
ntroversial, this is often the best way to proceed.</div></div></blockquote=
><div><br></div><div>Without going into the details but to make things slig=
htly less vague, one topic that we had consensus on was a way to allow a re=
gistered precondition violation handler to throw an exception with semantic=
s that would be satisfactory for those who were involved in both sides of t=
he discussion, and in a way that is also consistent with noexcept. In other=
words, the approach allows you to have a preconditions on both noexcept an=
d non-noexcept functions, and you are allowed to register a precondition ha=
ndler that throws rather than terminates. IIRC, we didn't yet get to a =
point where we had consensus around supporting handlers that can return (i.=
e. precondition violation handlers that neither terminate nor throw), but t=
he progress that was made was still an important step forward.</div></div><=
/div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c30caa4a87d705231be9de--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Tue, 27 Oct 2015 15:06:57 -0700 (PDT)
Raw View
------=_Part_1069_665841869.1445983617616
Content-Type: multipart/alternative;
boundary="----=_Part_1070_904879731.1445983617617"
------=_Part_1070_904879731.1445983617617
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu wtorek, 27 pa=C5=BAdziernika 2015 21:27:50 UTC+1 u=C5=BCytkownik Mat=
t=20
Calabrese napisa=C5=82:
>
> On Mon, Oct 26, 2015 at 6:22 AM, Alisdair Meredith <alis...@me.com=20
> <javascript:>> wrote:
>
>> There should be a document in the post-Kona mailing, in around 2 weeks.
>> Although we believe that we have consensus on a way to make progress, an=
d
>> hopefully a full proposal for the Jacksonville meeting in February, I=20
>> don=E2=80=99t want
>> to jinx that by jumping out of step to describe it before that. We have=
=20
>> =E2=80=98persuaded'
>> an interested neutral party (i.e., not associated with any of the initia=
l=20
>> proposers)
>> to produce the write-up for us, to avoid any accidental bias when=20
>> describing what
>> was agreed. When a topic has a wide design space and picking any point=
=20
>> in that
>> space proves controversial, this is often the best way to proceed.
>>
>
> Without going into the details but to make things slightly less vague, on=
e=20
> topic that we had consensus on was a way to allow a registered preconditi=
on=20
> violation handler to throw an exception with semantics that would be=20
> satisfactory for those who were involved in both sides of the discussion,=
=20
> and in a way that is also consistent with noexcept. In other words, the=
=20
> approach allows you to have a preconditions on both noexcept and=20
> non-noexcept functions, and you are allowed to register a precondition=20
> handler that throws rather than terminates. IIRC, we didn't yet get to a=
=20
> point where we had consensus around supporting handlers that can return=
=20
> (i.e. precondition violation handlers that neither terminate nor throw),=
=20
> but the progress that was made was still an important step forward.
>
Thank you for the information. "Throwing handlers" and "terminating=20
handlers" sounds like the preconditions are checked at run-time (and add=20
performance overhead?). I hope there will be a way for the Standard Library=
=20
vendor to guarantee to the users that no contracts-related overhead is=20
added. Looking forward to the full report in the mailing.
Regards,
&rzej =20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1070_904879731.1445983617617
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu wtorek, 27 pa=C5=BAdziernika 2015 21:27:50 UTC+1 u=C5=BCytko=
wnik Matt Calabrese 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><div class=3D"gmail_quote">On Mon, Oct 26, 2015 at=
6:22 AM, Alisdair Meredith <span dir=3D"ltr"><<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"fvott9ypEgAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"thi=
s.href=3D'javascript:';return true;">alis...@me.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word=
">There should be a document in the post-Kona mailing, in around 2 weeks.<d=
iv>Although we believe that we have consensus on a way to make progress, an=
d</div><div>hopefully a full proposal for the Jacksonville meeting in Febru=
ary, I don=E2=80=99t want</div><div>to jinx that by jumping out of step to =
describe it before that.=C2=A0 We have =E2=80=98persuaded'</div><div>an=
interested neutral party (i.e., not associated with any of the initial pro=
posers)</div><div>to produce the write-up for us, to avoid any accidental b=
ias when describing what</div><div>was agreed.=C2=A0 When a topic has a wid=
e design space and picking any point in that</div><div>space proves controv=
ersial, this is often the best way to proceed.</div></div></blockquote><div=
><br></div><div>Without going into the details but to make things slightly =
less vague, one topic that we had consensus on was a way to allow a registe=
red precondition violation handler to throw an exception with semantics tha=
t would be satisfactory for those who were involved in both sides of the di=
scussion, and in a way that is also consistent with noexcept. In other word=
s, the approach allows you to have a preconditions on both noexcept and non=
-noexcept functions, and you are allowed to register a precondition handler=
that throws rather than terminates. IIRC, we didn't yet get to a point=
where we had consensus around supporting handlers that can return (i.e. pr=
econdition violation handlers that neither terminate nor throw), but the pr=
ogress that was made was still an important step forward.</div></div></div>=
</div></blockquote><div><br>Thank you for the information. "Throwing h=
andlers" and "terminating handlers" sounds like the precondi=
tions are checked at run-time (and add performance overhead?). I hope there=
will be a way for the Standard Library vendor to guarantee to the users th=
at no contracts-related overhead is added. Looking forward to the full repo=
rt in the mailing.<br><br>Regards,<br>&rzej=C2=A0 <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1070_904879731.1445983617617--
------=_Part_1069_665841869.1445983617616--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 27 Oct 2015 15:23:27 -0700
Raw View
--001a113e23cae25e1d05231d86f4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Oct 27, 2015 at 3:06 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>
wrote:
>
> Thank you for the information. "Throwing handlers" and "terminating
> handlers" sounds like the preconditions are checked at run-time (and add
> performance overhead?). I hope there will be a way for the Standard Libra=
ry
> vendor to guarantee to the users that no contracts-related overhead is
> added.
>
Yes, it is planned to be allowable for an implementation to have no
overhead (not perform the checks). I forget precisely the details, but
IIRC, the idea is that it's somehow going to be explicitly possible to
guarantee that no precondition handler is allowed to be specified at
run-time (or maybe that it would be implementation-specified that the
registration call does anything?), and that in such a case, violation of
the preconditions will be UB and the conditions, in practice, wouldn't be
checked. I think this is something of a unique kind of specification for
the standard, and again, I don't remember the exact details, but it should
be possible for a compliant implementation to not perform checks. I'm going
by memory, and this wasn't perceived to be a particularly contentious
issue, so it wasn't heavily discussed.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a113e23cae25e1d05231d86f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 27, 2015 at 3:06 PM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr"><=
;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com=
</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Thank you for the=
information. "Throwing handlers" and "terminating handlers&=
quot; sounds like the preconditions are checked at run-time (and add perfor=
mance overhead?). I hope there will be a way for the Standard Library vendo=
r to guarantee to the users that no contracts-related overhead is added.</d=
iv></blockquote><div><br></div><div>Yes, it is planned to be allowable for =
an implementation to have no overhead (not perform the checks). I forget pr=
ecisely the details, but IIRC, the idea is that it's somehow going to b=
e explicitly possible to guarantee that no precondition handler is allowed =
to be specified at run-time (or maybe that it would be implementation-speci=
fied that the registration call does anything?), and that in such a case, v=
iolation of the preconditions will be UB and the conditions, in practice, w=
ouldn't be checked. I think this is something of a unique kind of speci=
fication for the standard, and again, I don't remember the exact detail=
s, but it should be possible for a compliant implementation to not perform =
checks. I'm going by memory, and this wasn't perceived to be a part=
icularly contentious issue, so it wasn't heavily discussed.</div></div>=
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113e23cae25e1d05231d86f4--
.
Author: Mathias Gaunard <mathias.gaunard@gmail.com>
Date: Wed, 4 Nov 2015 06:14:14 -0800 (PST)
Raw View
------=_Part_170_2008174743.1446646454822
Content-Type: multipart/alternative;
boundary="----=_Part_171_639500681.1446646454822"
------=_Part_171_639500681.1446646454822
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le mardi 27 octobre 2015 22:06:57 UTC, Andrzej Krzemie=C5=84ski a =C3=A9cri=
t :
>
>
>
> W dniu wtorek, 27 pa=C5=BAdziernika 2015 21:27:50 UTC+1 u=C5=BCytkownik M=
att=20
> Calabrese napisa=C5=82:
>>
>> On Mon, Oct 26, 2015 at 6:22 AM, Alisdair Meredith <alis...@me.com>=20
>> wrote:
>>
>>> There should be a document in the post-Kona mailing, in around 2 weeks.
>>> Although we believe that we have consensus on a way to make progress, a=
nd
>>> hopefully a full proposal for the Jacksonville meeting in February, I=
=20
>>> don=E2=80=99t want
>>> to jinx that by jumping out of step to describe it before that. We hav=
e=20
>>> =E2=80=98persuaded'
>>> an interested neutral party (i.e., not associated with any of the=20
>>> initial proposers)
>>> to produce the write-up for us, to avoid any accidental bias when=20
>>> describing what
>>> was agreed. When a topic has a wide design space and picking any point=
=20
>>> in that
>>> space proves controversial, this is often the best way to proceed.
>>>
>>
>> Without going into the details but to make things slightly less vague,=
=20
>> one topic that we had consensus on was a way to allow a registered=20
>> precondition violation handler to throw an exception with semantics that=
=20
>> would be satisfactory for those who were involved in both sides of the=
=20
>> discussion, and in a way that is also consistent with noexcept. In other=
=20
>> words, the approach allows you to have a preconditions on both noexcept =
and=20
>> non-noexcept functions, and you are allowed to register a precondition=
=20
>> handler that throws rather than terminates. IIRC, we didn't yet get to a=
=20
>> point where we had consensus around supporting handlers that can return=
=20
>> (i.e. precondition violation handlers that neither terminate nor throw),=
=20
>> but the progress that was made was still an important step forward.
>>
>
> Thank you for the information. "Throwing handlers" and "terminating=20
> handlers" sounds like the preconditions are checked at run-time (and add=
=20
> performance overhead?). I hope there will be a way for the Standard Libra=
ry=20
> vendor to guarantee to the users that no contracts-related overhead is=20
> added. Looking forward to the full report in the mailing.
>
Some people feel that checks should always be enforced, and that running=20
code after a violation should be UB to let compilers optimize more.
Some arguably more pragmatic people want the ability to disable the checks=
=20
or do nothing in the violation handler.
This is the core of the issue with contracts and why there is so much=20
debate.
In the end, it's all just going to be controlled by compiler options. So=20
it's only an issue as to how the actual implementation allows you to switch=
=20
between the modes, and how you can control (or not) what a third-party=20
library does.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_171_639500681.1446646454822
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>Le mardi 27 octobre 2015 22:06:57 UTC, Andrzej Krzemie=C5=84ski a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>W dni=
u wtorek, 27 pa=C5=BAdziernika 2015 21:27:50 UTC+1 u=C5=BCytkownik Matt Cal=
abrese napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote">On Mon, Oct 26, 2015 at 6:22 AM, Alisdair=
Meredith <span dir=3D"ltr"><<a rel=3D"nofollow">alis...@me.com</a>><=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:bre=
ak-word">There should be a document in the post-Kona mailing, in around 2 w=
eeks.<div>Although we believe that we have consensus on a way to make progr=
ess, and</div><div>hopefully a full proposal for the Jacksonville meeting i=
n February, I don=E2=80=99t want</div><div>to jinx that by jumping out of s=
tep to describe it before that.=C2=A0 We have =E2=80=98persuaded'</div>=
<div>an interested neutral party (i.e., not associated with any of the init=
ial proposers)</div><div>to produce the write-up for us, to avoid any accid=
ental bias when describing what</div><div>was agreed.=C2=A0 When a topic ha=
s a wide design space and picking any point in that</div><div>space proves =
controversial, this is often the best way to proceed.</div></div></blockquo=
te><div><br></div><div>Without going into the details but to make things sl=
ightly less vague, one topic that we had consensus on was a way to allow a =
registered precondition violation handler to throw an exception with semant=
ics that would be satisfactory for those who were involved in both sides of=
the discussion, and in a way that is also consistent with noexcept. In oth=
er words, the approach allows you to have a preconditions on both noexcept =
and non-noexcept functions, and you are allowed to register a precondition =
handler that throws rather than terminates. IIRC, we didn't yet get to =
a point where we had consensus around supporting handlers that can return (=
i.e. precondition violation handlers that neither terminate nor throw), but=
the progress that was made was still an important step forward.</div></div=
></div></div></blockquote><div><br>Thank you for the information. "Thr=
owing handlers" and "terminating handlers" sounds like the p=
reconditions are checked at run-time (and add performance overhead?). I hop=
e there will be a way for the Standard Library vendor to guarantee to the u=
sers that no contracts-related overhead is added. Looking forward to the fu=
ll report in the mailing.<br></div></blockquote><div><br></div><div>Some pe=
ople feel that checks should always be enforced, and that running code afte=
r a violation should be UB to let compilers optimize more.</div><div>Some a=
rguably more pragmatic people want the ability to disable the checks or do =
nothing in the violation handler.</div><div>This is the core of the issue w=
ith contracts and why there is so much debate.<br><br>In the end, it's =
all just going to be controlled by compiler options. So it's only an is=
sue as to how the actual implementation allows you to switch between the mo=
des, and how you can control (or not) what a third-party library does.</div=
>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_171_639500681.1446646454822--
------=_Part_170_2008174743.1446646454822--
.