------=_Part_1483_1141776903.1429312967146
Content-Type: multipart/alternative;
 boundary="----=_Part_1484_2078022776.1429312967146"

------=_Part_1484_2078022776.1429312967146
Content-Type: text/plain; charset=UTF-8

I'm reading through N4435 and while I believe in the goals of the proposal
I think it has a couple of unfortunate failings that need to be addressed:

1) Currently, the paper suggests treating violations in an
implementation-specified manner, giving the example that one implementation
may throw an exception. There are a couple of problems with this. First, by
making the behavior implementation-specified to such an extent that some
implementations may throw an exception, we'd be [ab]using the attribute
facility in a way that allows programs to change behavior due to whether or
not an attribute is handled by a compiler (I.E. a function invocation may
be noexcept in certain compilers but not others, and on that note, what if
you specify that a function is noexcept but with preconditions: would an
implementation terminate when the exception would propagate, or something
else?). This goes against the idea of attributes and could make dealing
with such behavior very difficult, especially regarding portability.

As well, a precondition violation should under no circumstance throw an
exception, since a precondition violation is by definition a bug rather
than a recoverable error. A precondition violation is always UB. If you
explicitly specify some kind of well-defined behavior, such as the throwing
of an exception, then you simply do no want that predicate to be a
precondition. Rather, by specifying the behavior on such a violation, you
are effectively stating that it is not a precondition, since users can now
pass such "invalid" data, and get a specified result.

2) The paper speaks of purity with respect to contract predicates, which I
agree is a necessity, however I believe it needs much more specific wording
regarding exactly what it means.

3) Type invariants are described here as preconditions and postconditions
that apply to every non-static member function. This is somewhat correct,
but there is an important difference that goes unmentioned: the
postcondition section states that a postcondition does not need to be met
if the function does not return, such as if an exception propagates. This
is proper behavior since an exception is precisely the way that an
algorithm's inability to meet a postcondition due to, for instance,
resource limits, is communicated back to a user. However, it is this
property of postconditions that makes the description of an invariant as
preconditions and postconditions that apply to all non-static member
functions only partially correct. The key difference is that a type's
invariants always hold even if an exception propagates, otherwise the
function wouldn't even meet the basic exception guarantee. This is a
subtle, but very important detail that needs to be made explicit.

4) Assuming #3 is agreed upon, this also implies that behavior for
constructors is slightly different with respect to type invariants, since a
constructor that throws an exception is allowed to not satisfy the
invariants, as the type is not actually constructed.

5) The paper states that type invariants pertain to all public and
protected non-static member functions, leaving out private member
functions. I understand why this is the case, but I suggest an alternative:
have type invariants pertain to all non-static member functions, including
private ones, unless a specific member function is somehow flagged as being
exempt from the invariant. I say this because some private member functions
may still be written in a way that respect the type's invariants.

6) User-customization of behavior on contract violations is often useful in
practice, even though such behavior would technically be executed when we
are already in UB land. For instance, you can imagine systems where, if the
process were to exit, you'd need to run some bit of code that sends a
message to another process for safety-critical reasons. I'm not entirely
sure what the correct solution to this is, though systems I've worked with
have handled things by way of quick exit and at quick exit. While this
"works," even that solution has always bugged me (pardon the pun) since the
implication is that you're executing even more user-defined code after
you've identified that there is some kind of UB. Such code may not behave
as expected/make the problem even worse/delay the ending of the process,
which risks seeing even more problems I.E. from other threads.

7) My top-level assessment is that attributes are probably not the best fit
if it is expected that the user should be able to rely on something
happening in the case that such a condition is detected as violated. On the
other hand, if customization isn't considered important, attributes can at
least be argued to be an appropriate fit... although even there I'm not
entirely convinced. For instance, if you are to think of attributes as not
affecting the overall visible behavior of the program, which is the
recommendation with respect to the design of the attributes facility in
C++, then doing something like [quick] exiting the program on a contract
violation might not be appropriate. I say this because the contract
specification itself is basically equivalent to a comment when seen from
implementations that do not handle the attribute. In other words, even the
fact that violation of the contract is UB only makes sense if the
implementation handles the attribute. Because of this, even treating the
contract violation as UB, in the sense that the implementation might do
something such as exit the process, is arguably a misuse of attributes,
since an implementation that doesn't handle the attribute may never
actually encounter anything in the language itself that is UB.

That last point might be considered overly pedantic, but I'm not sure it
should be glossed over too lightly.

Anyway, despite this blob of gripes, I really do agree with the overall
goals of this proposal. I would just prefer to see the issues directly
addressed.

--

---
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_1484_2078022776.1429312967146
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I'm reading through N4435 and while I believe in the goals=
 of the proposal I think it has a couple of unfortunate failings that need =
to be addressed:<div><br></div><div>1) Currently, the paper suggests treati=
ng violations in an implementation-specified manner, giving the example tha=
t one implementation may throw an exception. There are a couple of problems=
 with this. First, by making the behavior implementation-specified to such =
an extent that some implementations may throw an exception, we'd be [ab]usi=
ng the attribute facility in a way that allows programs to change behavior =
due to whether or not an attribute is handled by a compiler (I.E. a functio=
n invocation may be noexcept in certain compilers but not others, and on th=
at note, what if you specify that a function is noexcept but with precondit=
ions: would an implementation terminate when the exception would propagate,=
 or something else?). This goes against the idea of attributes and could ma=
ke dealing with such behavior very difficult, especially regarding portabil=
ity.</div><div><br></div><div>As well, a precondition violation should unde=
r no circumstance throw an exception, since a precondition violation is by =
definition a bug rather than a recoverable error. A precondition violation =
is always UB. If you explicitly specify some kind of well-defined behavior,=
 such as the throwing of an exception, then you simply do no want that pred=
icate to be a precondition. Rather, by specifying the behavior on such a vi=
olation, you are effectively stating that it is not a precondition, since u=
sers can now pass such "invalid" data, and get a specified result.</div><di=
v><br></div><div>2) The paper speaks of purity with respect to contract pre=
dicates, which I agree is a necessity, however I believe it needs much more=
 specific wording regarding exactly what it means.</div><div><br></div><div=
>3) Type invariants are described here as preconditions and postconditions =
that apply to every non-static member function. This is somewhat correct, b=
ut there is an important difference that goes unmentioned: the postconditio=
n section states that a postcondition does not need to be met if the functi=
on does not return, such as if an exception propagates. This is proper beha=
vior since an exception is precisely the way that an algorithm's inability =
to meet a postcondition due to, for instance, resource limits, is communica=
ted back to a user. However, it is this property of postconditions that mak=
es the description of an invariant as preconditions and postconditions that=
 apply to all non-static member functions only partially correct. The key d=
ifference is that a type's invariants always hold even if an exception prop=
agates, otherwise the function wouldn't even meet the basic exception guara=
ntee. This is a subtle, but very important detail that needs to be made exp=
licit.</div><div><br></div><div>4) Assuming #3 is agreed upon, this also im=
plies that behavior for constructors is slightly different with respect to =
type invariants, since a constructor that throws an exception is allowed to=
 not satisfy the invariants, as the type is not actually constructed.</div>=
<div><br></div><div>5) The paper states that type invariants pertain to all=
 public and protected non-static member functions, leaving out private memb=
er functions. I understand why this is the case, but I suggest an alternati=
ve: have type invariants pertain to all non-static member functions, includ=
ing private ones, unless a specific member function is somehow flagged as b=
eing exempt from the invariant. I say this because some private member func=
tions may still be written in a way that respect the type's invariants.</di=
v><div><br></div><div>6) User-customization of behavior on contract violati=
ons is often useful in practice, even though such behavior would technicall=
y be executed when we are already in UB land. For instance, you can imagine=
 systems where, if the process were to exit, you'd need to run some bit of =
code that sends a message to another process for safety-critical reasons. I=
'm not entirely sure what the correct solution to this is, though systems I=
've worked with have handled things by way of quick exit and at quick exit.=
 While this "works," even that solution has always bugged me (pardon the pu=
n) since the implication is that you're executing even more user-defined co=
de after you've identified that there is some kind of UB. Such code may not=
 behave as expected/make the problem even worse/delay the ending of the pro=
cess, which risks seeing even more problems I.E. from other threads.</div><=
div><br></div><div>7) My top-level assessment is that attributes are probab=
ly not the best fit if it is expected that the user should be able to rely =
on something happening in the case that such a condition is detected as vio=
lated. On the other hand, if customization isn't considered important, attr=
ibutes can at least be argued to be an appropriate fit... although even the=
re I'm not entirely convinced. For instance, if you are to think of attribu=
tes as not affecting the overall visible behavior of the program, which is =
the recommendation with respect to the design of the attributes facility in=
 C++, then doing something like [quick] exiting the program on a contract v=
iolation might not be appropriate. I say this because the contract specific=
ation itself is basically equivalent to a comment when seen from implementa=
tions that do not handle the attribute. In other words, even the fact that =
violation of the contract is UB only makes sense if the implementation hand=
les the attribute. Because of this, even treating the contract violation as=
 UB, in the sense that the implementation might do something such as exit t=
he process, is arguably a misuse of attributes, since an implementation tha=
t doesn't handle the attribute may never actually encounter anything in the=
 language itself that is UB.</div><div><br></div><div>That last point might=
 be considered overly pedantic, but I'm not sure it should be glossed over =
too lightly.</div><div><br></div><div>Anyway, despite this blob of gripes, =
I really do agree with the overall goals of this proposal. I would just pre=
fer to see the issues directly addressed.</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&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 />
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_1484_2078022776.1429312967146--
------=_Part_1483_1141776903.1429312967146--

.

--001a11c3ce14d5b9ad0513f4654f
Content-Type: text/plain; charset=UTF-8

On 17 April 2015 at 18:22, Matt Calabrese <calabrese@google.com> wrote:

> As well, a precondition violation should under no circumstance throw an
> exception, since a precondition violation is by definition a bug rather
> than a recoverable error. A precondition violation is always UB.
>

We keep trying to *define* *undefined behavior.*

When I said in a plenary session in Madrid that one should be able to throw
on a precondition violation through a noexcept clause because you are
already in UB-land, I was told that "noexcept trumps undefined behavior".
How does that not *define undefined behavior*?

Constexpr is *defined* to detect and terminate when it detects UB in a
constexpr context.  Well, not really, as it doesn't usually detect library
precondition violations, nor do most folks expect it to do so.  Some people
think we should now *define* two different kinds of UB because of it, which
pretty much violates what it means to be *undefined*.

We desperately, desperately need terminology that doesn't include the word
*undefined* for things that have any sort of *defined* behavior.


> 5) The paper states that type invariants pertain to all public and
> protected non-static member functions, leaving out private member
> functions. I understand why this is the case, but I suggest an alternative:
> have type invariants pertain to all non-static member functions, including
> private ones, unless a specific member function is somehow flagged as being
> exempt from the invariant. I say this because some private member functions
> may still be written in a way that respect the type's invariants.
>

I disagree.  My big fear is that all this contract stuff will make code
very noisy.  I shouldn't have to opt-out for private non-virtual functions
(private virtual functions may be part of the public or protected interface
and are a different story).
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

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

<div dir=3D"ltr">On 17 April 2015 at 18:22, Matt Calabrese <span dir=3D"ltr=
">&lt;<a href=3D"mailto:calabrese@google.com" target=3D"_blank">calabrese@g=
oogle.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>As well,=
 a precondition violation should under no circumstance throw an exception, =
since a precondition violation is by definition a bug rather than a recover=
able error. A precondition violation is always UB.</div></div></blockquote>=
<div><br></div><div>We keep trying to <i><u>define</u></i>=C2=A0<i>undefine=
d behavior.</i></div><div><i><br></i></div><div>When I said in a plenary se=
ssion in Madrid that one should be able to throw on a precondition violatio=
n through a noexcept clause because you are already in UB-land, I was told =
that &quot;noexcept trumps undefined behavior&quot;.=C2=A0 How does that no=
t <i>define undefined behavior</i>?</div><div><br></div><div>Constexpr is <=
i>defined</i> to detect and terminate when it detects UB in a constexpr con=
text.=C2=A0 Well, not really, as it doesn&#39;t usually detect library prec=
ondition violations, nor do most folks expect it to do so.=C2=A0 Some peopl=
e think we should now=C2=A0<i>define</i> two different kinds of UB because =
of it, which pretty much violates what it means to be <i>undefined</i>.</di=
v><div><br></div><div>We desperately, desperately need terminology that doe=
sn&#39;t include the word <i>undefined</i>=C2=A0for things that have any so=
rt of <i>defined</i> behavior.</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div>5) The paper states that type invariants per=
tain to all public and protected non-static member functions, leaving out p=
rivate member functions. I understand why this is the case, but I suggest a=
n alternative: have type invariants pertain to all non-static member functi=
ons, including private ones, unless a specific member function is somehow f=
lagged as being exempt from the invariant. I say this because some private =
member functions may still be written in a way that respect the type&#39;s =
invariants.<br></div></div></blockquote><div><br></div><div>I disagree.=C2=
=A0 My big fear is that all this contract stuff will make code very noisy.=
=C2=A0 I shouldn&#39;t have to opt-out for private non-virtual functions (p=
rivate virtual functions may be part of the public or protected interface a=
nd are a different story).=C2=A0</div></div>-- <br><div class=3D"gmail_sign=
ature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=C2=A0 (847) 691-1404</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&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 />
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 />

--001a11c3ce14d5b9ad0513f4654f--

.

------=_Part_1544_217347578.1429344508627
Content-Type: multipart/alternative;
 boundary="----=_Part_1545_91059899.1429344508628"

------=_Part_1545_91059899.1429344508628
Content-Type: text/plain; charset=UTF-8


My two cents:

1 - We should be able to define the exception, in case of the violation of
the pre/post condition

class A {
  T& operator[](size_t i) [[expects: i < size(); throw out_of_range(string("parameter
invalid") + to_string(i) );]];
};


Exceptions are better with further information

2 - What happens if the class A above is a concurrent linked list and
"size_t size() const" function involves locks and o(n) behavior, and
concludes that is the pre-condition is satisfied, but executing ...  well,
you got it...

3 - The pre-condition is executed before or after the parameters are passed
(and probably copied) ? The answer may implies some destruction when throw
the exception;

CSS

--

---
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_1545_91059899.1429344508628
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>My two cents:</div><div><br></div><div=
>1 - We should be able to define the exception, in case of the violation of=
 the pre/post condition</div><div><br></div><div><div class=3D"prettyprint"=
 style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; back=
ground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">class A {<br>&nbsp; T</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
operator</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">size_t i<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">expects</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> size</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">throw</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: rgb(0, 0, 0); font-family: DejaVuSansMono, 'DejaVu Sans M=
ono', courier, monospace; font-size: 12.8000001907349px; line-height: 14.07=
99999237061px; white-space: nowrap; background-color: rgb(248, 248, 248);">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">out_of_range</spa=
n></span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<font color=3D"#666600"><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">string</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span></font><span style=3D"color: #080;" class=3D"styled-by-prettify"=
>"parameter invalid"</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp;</span><spa=
n style=3D"color: rgb(0, 0, 0); font-family: DejaVuSansMono, 'DejaVu Sans M=
ono', courier, monospace; font-size: 12.8000001907349px; line-height: 14.07=
99999237061px; white-space: nowrap; background-color: rgb(255, 255, 255);">=
to_string(</span><span class=3D"styled-by-prettify" style=3D"font-family: A=
rial, Helvetica, sans-serif; color: rgb(0, 0, 0);">i)&nbsp;</span><span cla=
ss=3D"styled-by-prettify" style=3D"font-family: Arial, Helvetica, sans-seri=
f; color: rgb(102, 102, 0);">);]];<br>};</span></div><div class=3D"subprett=
yprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n></div></code></div><div><br></div>Exceptions are better with further info=
rmation&nbsp;<br></div><div><br></div><div>2 - What happens if the class A =
above is a concurrent linked list and "size_t size() const" function involv=
es locks and o(n) behavior, and concludes that is the pre-condition is sati=
sfied, but executing ... &nbsp;well, you got it...&nbsp;</div><div><br></di=
v><div>3 - The pre-condition is executed before or after the parameters are=
 passed (and probably copied) ? The answer may implies some destruction whe=
n throw the exception;<br></div><div><br></div><div>CSS&nbsp;</div><div><br=
></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
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_1545_91059899.1429344508628--
------=_Part_1544_217347578.1429344508627--

.

--e89a8fb1f324359a010514027918
Content-Type: text/plain; charset=UTF-8

On Fri, Apr 17, 2015 at 8:00 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 17 April 2015 at 18:22, Matt Calabrese <calabrese@google.com> wrote:
>
>> As well, a precondition violation should under no circumstance throw an
>> exception, since a precondition violation is by definition a bug rather
>> than a recoverable error. A precondition violation is always UB.
>>
>
> We keep trying to *define* *undefined behavior.*
>

This is silly and counterproductive unless the undefined behavior simply
should not be undefined.


> When I said in a plenary session in Madrid that one should be able to
> throw on a precondition violation through a noexcept clause because you are
> already in UB-land, I was told that "noexcept trumps undefined behavior".
> How does that not *define undefined behavior*?
>

We shouldn't be throwing on a precondition violation to begin with. If the
caller violates a contract (the precondition), then they did so either
because of incorrect information regarding what the preconditions of the
function were, or because of incorrect assumptions about other invariants,
or because they are in UB land already, etc. In other words there is a bug,
which means throwing an exception that can be handled (or even one that
goes entirely unhandled) is a very bad idea as it only serves to execute
more code while the program is in an unhandled state.

Constexpr is *defined* to detect and terminate when it detects UB in a
> constexpr context.  Well, not really, as it doesn't usually detect library
> precondition violations, nor do most folks expect it to do so.  Some people
> think we should now *define* two different kinds of UB because of it,
> which pretty much violates what it means to be *undefined*.
>

:(


> We desperately, desperately need terminology that doesn't include the word
> *undefined* for things that have any sort of *defined* behavior.
>

Agreed.


>
>
>> 5) The paper states that type invariants pertain to all public and
>> protected non-static member functions, leaving out private member
>> functions. I understand why this is the case, but I suggest an alternative:
>> have type invariants pertain to all non-static member functions, including
>> private ones, unless a specific member function is somehow flagged as being
>> exempt from the invariant. I say this because some private member functions
>> may still be written in a way that respect the type's invariants.
>>
>
> I disagree.  My big fear is that all this contract stuff will make code
> very noisy.  I shouldn't have to opt-out for private non-virtual functions
> (private virtual functions may be part of the public or protected interface
> and are a different story).
>

Why? I think it's really weird and inconsistent that we are treating
private functions different here, effectively assuming that by nature of
being private, they never care about the type invariants. Yes, such
functions do exist and are fine when private, but only the programmer knows
when that is the case. It is not intrinsic to a function being private.

--

---
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/.

--e89a8fb1f324359a010514027918
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 F=
ri, Apr 17, 2015 at 8:00 PM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span =
class=3D"">On 17 April 2015 at 18:22, Matt Calabrese <span dir=3D"ltr">&lt;=
<a href=3D"mailto:calabrese@google.com" target=3D"_blank">calabrese@google.=
com</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>As well, a precondition violation should under no circumstanc=
e throw an exception, since a precondition violation is by definition a bug=
 rather than a recoverable error. A precondition violation is always UB.</d=
iv></div></blockquote><div><br></div></span><div>We keep trying to <i><u>de=
fine</u></i>=C2=A0<i>undefined behavior.</i></div></div></div></div></block=
quote><div><br></div><div>This is silly and counterproductive unless the un=
defined behavior simply should not be undefined.=C2=A0</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><div>When I said in a plenary session in Madri=
d that one should be able to throw on a precondition violation through a no=
except clause because you are already in UB-land, I was told that &quot;noe=
xcept trumps undefined behavior&quot;.=C2=A0 How does that not <i>define un=
defined behavior</i>?<br></div></div></div></div></blockquote><div><br></di=
v><div>We shouldn&#39;t be throwing on a precondition violation to begin wi=
th. If the caller violates a contract (the precondition), then they did so =
either because of incorrect information regarding what the preconditions of=
 the function were, or because of incorrect assumptions about other invaria=
nts, or because they are in UB land already, etc. In other words there is a=
 bug, which means throwing an exception that can be handled (or even one th=
at goes entirely unhandled) is a very bad idea as it only serves to execute=
 more code while the program is in an unhandled state.</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div></div><div>Constexpr is <i>defined</i> to d=
etect and terminate when it detects UB in a constexpr context.=C2=A0 Well, =
not really, as it doesn&#39;t usually detect library precondition violation=
s, nor do most folks expect it to do so.=C2=A0 Some people think we should =
now=C2=A0<i>define</i> two different kinds of UB because of it, which prett=
y much violates what it means to be <i>undefined</i>.<br></div></div></div>=
</div></blockquote><div><br></div><div>:(</div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div></div><div>We desperately, desperately need terminolo=
gy that doesn&#39;t include the word <i>undefined</i>=C2=A0for things that =
have any sort of <i>defined</i> behavior.<br></div></div></div></div></bloc=
kquote><div><br></div><div>Agreed.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div></div><span class=3D""><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div>5) The paper states that type invariants p=
ertain to all public and protected non-static member functions, leaving out=
 private member functions. I understand why this is the case, but I suggest=
 an alternative: have type invariants pertain to all non-static member func=
tions, including private ones, unless a specific member function is somehow=
 flagged as being exempt from the invariant. I say this because some privat=
e member functions may still be written in a way that respect the type&#39;=
s invariants.<br></div></div></blockquote><div><br></div></span><div>I disa=
gree.=C2=A0 My big fear is that all this contract stuff will make code very=
 noisy.=C2=A0 I shouldn&#39;t have to opt-out for private non-virtual funct=
ions (private virtual functions may be part of the public or protected inte=
rface and are a different story).</div></div></div></div></blockquote><div>=
<br></div><div>Why? I think it&#39;s really weird and inconsistent that we =
are treating private functions different here, effectively assuming that by=
 nature of being private, they never care about the type invariants. Yes, s=
uch functions do exist and are fine when private, but only the programmer k=
nows when that is the case. It is not intrinsic to a function being private=
..</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&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 />
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 />

--e89a8fb1f324359a010514027918--

.

--047d7b2e4c04ac3aad05140303f8
Content-Type: text/plain; charset=UTF-8

On Sat, Apr 18, 2015 at 4:08 AM, Cleiton Santoia <cleitonsantoia@gmail.com>
wrote:

>
> My two cents:
>
> 1 - We should be able to define the exception, in case of the violation of
> the pre/post condition
>
> class A {
>   T& operator[](size_t i) [[expects: i < size(); throw out_of_range(string
> ("parameter invalid") + to_string(i) );]];
> };
>
>
>
Please do not encourage this. If you throw on invalid input, then that
particular class of input simply is not invalid since you are specifying
behavior that a user can rely on when the condition fails (I.E. the clause
is no longer a precondition). It also now means that the condition should
be checked all of the time, otherwise the answer to what happens on invalid
input is "well... sometimes an exception is thrown." This is really silly.
It's either UB or its not, and if you have managed to detect UB, continuing
along in a way that tries to "handle" the UB by way on an exception is a
serious mistake.

Note that this is the entire difference between operator[] and at() for a
vector. The operator[] has a size precondition while the at() member
function does not. This is why at() checks and throws while operator[] is
just UB.

Regarding post-condition failures -- if the person who wrote the function
cannot knowingly meet the post-condition, then it is their responsibility
to throw an exception and not the contract specification's, since if the
check occurs while a value is returned, we've already encountered a bug, as
the programmer of the function actually thought they were returning a valid
result!

Just like with the precondition, you shouldn't be relying on the
post-condition clause to be consistently and automatically checked, nor for
it to do this kind of work during a return, for many of the same reasons
why you don't want to specify behavior on a specified precondition failure
from the precondition clause. Even if you were to specify some kind of an
exception to be thrown, the exception that it throws would necessarily be
limited in the information that it can include since such information might
only be available at a tighter scope inside of the function. As well, the
person writing the function can often determine the issue in code in a
better/more efficient way than a check that appears in a return without
even any of the function's stack-allocated data value for information.

2 - What happens if the class A above is a concurrent linked list and
> "size_t size() const" function involves locks and o(n) behavior, and
> concludes that is the pre-condition is satisfied, but executing ...  well,
> you got it...
>

Right, this is why some contract clauses shouldn't be checked even in an
implementation's "debug" builds (checks that would change the function's
order of complexity if run are the most obvious examples). There probably
should be some way to specify this when writing the contract, since it's
unreasonable to assume that the compiler can determine which conditions
shouldn't be checked at all.

--

---
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/.

--047d7b2e4c04ac3aad05140303f8
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 S=
at, Apr 18, 2015 at 4:08 AM, Cleiton Santoia <span dir=3D"ltr">&lt;<a href=
=3D"mailto:cleitonsantoia@gmail.com" target=3D"_blank">cleitonsantoia@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><br></=
div><div>My two cents:</div><div><br></div><div>1 - We should be able to de=
fine the exception, in case of the violation of the pre/post condition</div=
><div><br></div><div><div style=3D"border:1px solid rgb(187,187,187);word-w=
rap:break-word;background-color:rgb(250,250,250)"><code><div><span style=3D=
"color:rgb(0,0,0)">class A {<br>=C2=A0 T</span><span style=3D"color:rgb(102=
,102,0)">&amp;</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,102,0)"=
>[](</span><span style=3D"color:rgb(0,0,0)">size_t i</span><span style=3D"c=
olor:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </span><span=
 style=3D"color:rgb(102,102,0)">[[</span><span style=3D"color:rgb(0,0,0)">e=
xpects</span><span style=3D"color:rgb(102,102,0)">:</span><span style=3D"co=
lor:rgb(0,0,0)"> i </span><span style=3D"color:rgb(102,102,0)">&lt;</span><=
span style=3D"color:rgb(0,0,0)"> size</span><span style=3D"color:rgb(102,10=
2,0)">();</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"col=
or:rgb(0,0,136)">throw</span><span style=3D"color:rgb(0,0,0)"> </span><span=
 style=3D"color:rgb(0,0,0);font-family:DejaVuSansMono,&#39;DejaVu Sans Mono=
&#39;,courier,monospace;font-size:12.8000001907349px;line-height:14.0799999=
237061px;white-space:nowrap;background-color:rgb(248,248,248)"><span style=
=3D"color:rgb(0,0,0)">out_of_range</span></span><span style=3D"color:rgb(10=
2,102,0)">(</span><font color=3D"#666600"><span style=3D"color:rgb(0,0,136)=
">string</span><span style=3D"color:rgb(102,102,0)">(</span></font><span st=
yle=3D"color:rgb(0,136,0)">&quot;parameter invalid&quot;</span><span style=
=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(102,102,0)">+</span><span style=3D"color:rgb(0,0,0=
)">=C2=A0</span><span style=3D"color:rgb(0,0,0);font-family:DejaVuSansMono,=
&#39;DejaVu Sans Mono&#39;,courier,monospace;font-size:12.8000001907349px;l=
ine-height:14.0799999237061px;white-space:nowrap;background-color:rgb(255,2=
55,255)">to_string(</span><span style=3D"font-family:Arial,Helvetica,sans-s=
erif;color:rgb(0,0,0)">i)=C2=A0</span><span style=3D"font-family:Arial,Helv=
etica,sans-serif;color:rgb(102,102,0)">);]];<br>};</span></div><div><span s=
tyle=3D"color:rgb(0,0,0)"><br></span></div></code></div><div><br></div></di=
v></div></blockquote><div><br></div><div>Please do not encourage this. If y=
ou throw on invalid input, then that particular class of input simply is no=
t invalid since you are specifying behavior that a user can rely on when th=
e condition fails (I.E. the clause is no longer a precondition). It also no=
w means that the condition should be checked all of the time, otherwise the=
 answer to what happens on invalid input is &quot;well... sometimes an exce=
ption is thrown.&quot; This is really silly. It&#39;s either UB or its not,=
 and if you have managed to detect UB, continuing along in a way that tries=
 to &quot;handle&quot; the UB by way on an exception is a serious mistake.<=
/div><div><br></div><div>Note that this is the entire difference between op=
erator[] and at() for a vector. The operator[] has a size precondition whil=
e the at() member function does not. This is why at() checks and throws whi=
le operator[] is just UB.</div><div><br></div><div>Regarding post-condition=
 failures -- if the person who wrote the function cannot knowingly meet the=
 post-condition, then it is their responsibility to throw an exception and =
not the contract specification&#39;s, since if the check occurs while a val=
ue is returned, we&#39;ve already encountered a bug, as the programmer of t=
he function actually thought they were returning a valid result!</div><div>=
<br></div><div>Just like with the precondition, you shouldn&#39;t be relyin=
g on the post-condition clause to be consistently and automatically checked=
, nor for it to do this kind of work during a return, for many of the same =
reasons why you don&#39;t want to specify behavior on a specified precondit=
ion failure from the precondition clause. Even if you were to specify some =
kind of an exception to be thrown, the exception that it throws would neces=
sarily be limited in the information that it can include since such informa=
tion might only be available at a tighter scope inside of the function. As =
well, the person writing the function can often determine the issue in code=
 in a better/more efficient way than a check that appears in a return witho=
ut even any of the function&#39;s stack-allocated data value for informatio=
n.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>2 - What happ=
ens if the class A above is a concurrent linked list and &quot;size_t size(=
) const&quot; function involves locks and o(n) behavior, and concludes that=
 is the pre-condition is satisfied, but executing ... =C2=A0well, you got i=
t...<br></div></div></blockquote><div><br></div><div>Right, this is why som=
e contract clauses shouldn&#39;t be checked even in an implementation&#39;s=
 &quot;debug&quot; builds (checks that would change the function&#39;s orde=
r of complexity if run are the most obvious examples). There probably shoul=
d be some way to specify this when writing the contract, since it&#39;s unr=
easonable to assume that the compiler can determine which conditions should=
n&#39;t be checked at all.<br></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&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 />
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 />

--047d7b2e4c04ac3aad05140303f8--

.

------=_Part_2050_383540819.1429392671198
Content-Type: multipart/alternative;
 boundary="----=_Part_2051_1572120286.1429392671198"

------=_Part_2051_1572120286.1429392671198
Content-Type: text/plain; charset=UTF-8



>
> Constexpr is *defined* to detect and terminate when it detects UB in a
> constexpr context.  Well, not really, as it doesn't usually detect library
> precondition violations, nor do most folks expect it to do so.  Some people
> think we should now *define* two different kinds of UB because of it,
> which pretty much violates what it means to be *undefined*.
>

N4160 tries to address it by requiring that preconditions for constexpr
functions be also core constant expressions, and thereby verifiable at
compile-time.


> We desperately, desperately need terminology that doesn't include the word
> *undefined* for things that have any sort of *defined* behavior.
>

An alternative approach (indicated in N4160) would be to call a
precondition breach an ordinary UB: no std::terminate() guaranteed. The
purpose of UB would be only to assist static analyzers and optimizers.

Guaranteeing any run-time evaluation of preconditions sends the message to
the community that the language may not be suitable for
performance-critical applications.

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_2051_1572120286.1429392671198
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>Constexpr is <=
i>defined</i> to detect and terminate when it detects UB in a constexpr con=
text.&nbsp; Well, not really, as it doesn't usually detect library precondi=
tion violations, nor do most folks expect it to do so.&nbsp; Some people th=
ink we should now&nbsp;<i>define</i> two different kinds of UB because of i=
t, which pretty much violates what it means to be <i>undefined</i>.</div></=
div></div></div></blockquote><div><br>N4160 tries to address it by requirin=
g that preconditions for constexpr functions be also core constant expressi=
ons, and thereby verifiable at compile-time.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><div><br></div><div>We desperately, desperately need terminology that doe=
sn't include the word <i>undefined</i>&nbsp;for things that have any sort o=
f <i>defined</i> behavior.</div></div></div></div></blockquote><div><br>An =
alternative approach (indicated in N4160)  would be to call a precondition =
breach an ordinary UB: no std::terminate() guaranteed. The purpose of UB wo=
uld be only to assist static analyzers and optimizers.<br><br>Guaranteeing =
any run-time evaluation of preconditions sends the message to the community=
 that the language may not be suitable for performance-critical application=
s. <br><br>Regards,<br>&amp;rzej<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
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_2051_1572120286.1429392671198--
------=_Part_2050_383540819.1429392671198--

.

------=_Part_560_1574932569.1429399194773
Content-Type: multipart/alternative;
 boundary="----=_Part_561_8254261.1429399194773"

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


>
>
> Please do not encourage this. If you throw on invalid input, then that=20
> particular class of input simply is not invalid since you are specifying=
=20
> behavior that a user can rely on when the condition fails (I.E. the claus=
e=20
> is no longer a precondition). It also now means that the condition should=
=20
> be checked all of the time, otherwise the answer to what happens on inval=
id=20
> input is "well... sometimes an exception is thrown." This is really silly=
..=20
> It's either UB or its not, and if you have managed to detect UB, continui=
ng=20
> along in a way that tries to "handle" the UB by way on an exception is a=
=20
> serious mistake.
>

I'm not saying that we should abolish UB. In the paper says "For example,=
=20
the implementation may generate code to evaluate the expression at call=20
sites, or not. If such code is generated, the implementation may, for=20
example, choose to generate code that throws an exeception if precondition=
=20
evaluation proves false";

It=C2=B4s not required to compiler put the code to check that at runtime, I=
 got=20
this but, if for a number of obscure reasons, the implementation decides to=
=20
throw an exception, I'm just saying that it's better that you decides what=
=20
to throw, you may give a "exception hint" to the compiler in this=20
"implementation defined" part to do a more usefull thing.


BR
CSS

--=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_561_8254261.1429399194773
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><br>Please do not encourage this. If you thr=
ow on invalid input, then that particular class of input simply is not inva=
lid since you are specifying behavior that a user can rely on when the cond=
ition fails (I.E. the clause is no longer a precondition). It also now mean=
s that the condition should be checked all of the time, otherwise the answe=
r to what happens on invalid input is "well... sometimes an exception is th=
rown." This is really silly. It's either UB or its not, and if you have man=
aged to detect UB, continuing along in a way that tries to "handle" the UB =
by way on an exception is a serious mistake.<br></div></div></blockquote><d=
iv><br></div><div>I'm not saying that we should abolish UB. In the paper sa=
ys "For example, the implementation may generate code to evaluate
the expression at call sites, or not. If such code is generated, the implem=
entation may, for example,
choose to generate code that throws an exeception if precondition evaluatio=
n proves false";</div><div><br></div><div>It=C2=B4s not required to compile=
r put the code to check that at runtime, I got this but, if for a number of=
 obscure reasons, the implementation decides to throw an exception,&nbsp;I'=
m just saying that&nbsp;it's better that you decides what to throw, you may=
 give a "exception hint" to the compiler in this "implementation defined" p=
art to do a more usefull thing.</div><div><br></div><div><br></div><div>BR<=
/div><div>CSS</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&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 />
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_561_8254261.1429399194773--
------=_Part_560_1574932569.1429399194773--

.

This is a multi-part message in MIME format.
--------------090500000001030505020604
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 19/04/15 01:19, Cleiton Santoia a =C3=A9crit :
>
>
>     Please do not encourage this. If you throw on invalid input, then
>     that particular class of input simply is not invalid since you are
>     specifying behavior that a user can rely on when the condition
>     fails (I.E. the clause is no longer a precondition). It also now
>     means that the condition should be checked all of the time,
>     otherwise the answer to what happens on invalid input is "well...
>     sometimes an exception is thrown." This is really silly. It's
>     either UB or its not, and if you have managed to detect UB,
>     continuing along in a way that tries to "handle" the UB by way on
>     an exception is a serious mistake.
>
>
> I'm not saying that we should abolish UB. In the paper says "For=20
> example, the implementation may generate code to evaluate the=20
> expression at call sites, or not. If such code is generated, the=20
> implementation may, for example, choose to generate code that throws=20
> an exeception if precondition evaluation proves false";
>
> It=C2=B4s not required to compiler put the code to check that at runtime,=
 I=20
> got this but, if for a number of obscure reasons, the implementation=20
> decides to throw an exception, I'm just saying that it's better that=20
> you decides what to throw, you may give a "exception hint" to the=20
> compiler in this "implementation defined" part to do a more usefull thing=
..
>
Other languages associate a string to the pre/post-conditions and=20
invariants so that a clear message can be reported. Note that I'm not at=20
all for defining what should happen when the conditions are violated.

I don't believe neither that we need to remove the noexcept of a narrow=20
function, just because the compiler could throw an exception if the=20
conditions are violated. Extrapolating this would mean that any function=20
that can violate the invariants cannot be noexcept. This would imply=20
that the user wouldn't add invariants when noexcept must be used.

Vicente

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 19/04/15 01:19, Cleiton Santoia a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:b0231de8-dd04-4aab-b63a-fe1a345a8fa8@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <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 class=3D"gmail_quote"><br>
              Please do not encourage this. If you throw on invalid
              input, then that particular class of input simply is not
              invalid since you are specifying behavior that a user can
              rely on when the condition fails (I.E. the clause is no
              longer a precondition). It also now means that the
              condition should be checked all of the time, otherwise the
              answer to what happens on invalid input is "well...
              sometimes an exception is thrown." This is really silly.
              It's either UB or its not, and if you have managed to
              detect UB, continuing along in a way that tries to
              "handle" the UB by way on an exception is a serious
              mistake.<br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>I'm not saying that we should abolish UB. In the paper says
          "For example, the implementation may generate code to evaluate
          the expression at call sites, or not. If such code is
          generated, the implementation may, for example,
          choose to generate code that throws an exeception if
          precondition evaluation proves false";</div>
        <div><br>
        </div>
        <div>It=C2=B4s not required to compiler put the code to check that =
at
          runtime, I got this but, if for a number of obscure reasons,
          the implementation decides to throw an exception,=C2=A0I'm just
          saying that=C2=A0it's better that you decides what to throw, you
          may give a "exception hint" to the compiler in this
          "implementation defined" part to do a more usefull thing.</div>
        <br>
      </div>
    </blockquote>
    Other languages associate a string to the pre/post-conditions and
    invariants so that a clear message can be reported. Note that I'm
    not at all for defining what should happen when the conditions are
    violated.<br>
    <br>
    I don't believe neither that we need to remove the noexcept of a
    narrow function, just because the compiler could throw an exception
    if the conditions are violated. Extrapolating this would mean that
    any function that can violate the invariants cannot be noexcept.
    This would imply that the user wouldn't add invariants when noexcept
    must be used.<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
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 />

--------------090500000001030505020604--

.

On Fri, Apr 17, 2015 at 8:00 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 17 April 2015 at 18:22, Matt Calabrese <calabrese@google.com> wrote:
>>
>> 5) The paper states that type invariants pertain to all public and
>> protected non-static member functions, leaving out private member functions.
>> I understand why this is the case, but I suggest an alternative: have type
>> invariants pertain to all non-static member functions, including private
>> ones, unless a specific member function is somehow flagged as being exempt
>> from the invariant. I say this because some private member functions may
>> still be written in a way that respect the type's invariants.
>
>
> I disagree.  My big fear is that all this contract stuff will make code very
> noisy.  I shouldn't have to opt-out for private non-virtual functions
> (private virtual functions may be part of the public or protected interface
> and are a different story).

My big complain about class invariant is that it does not
work on ADL interfaces.  Member functions contribute to
only one part of class interfaces.

Maybe we can apply the [[inv: ]] attribute to access specifiers
instead:

  public [[inv: (invariants())]] :
  ...

So that you can switch.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
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/.

.

--001a11c3c1b809cff605142349a4
Content-Type: text/plain; charset=UTF-8

Just 2c:

Whenever you have undefined behavior "anything" goes, an implementation
should be free to throw an exception. We do this extensively in our code,
in release mode precondition checks may be removed from parts or all of the
program, in debug it aborts the program, inside test drivers it throws an
exception that identifies the source and can be captured and analyzed.  The
ability of producing known behavior through configuration of the build/run
process in tests enables us to verify that the components would be able to
detect the invalid inputs and abort.

I have not read the paper in detail, but there are already cases where
calling a function with the 'noexcept' exception specification may end up
in an exception being thrown and terminate not being called: copy/move
constructors for arguments passed in by value and conversions for arguments
that need to be converted. The 'noexcept specification applies to the body
of the function (or the initializer list + body for constructors), so there
operations may already throw.  The next question is where preconditions
should be checked, if the code is injected into the caller, it would be
perfectly fine to allow a precondition exception to be thrown on a
'noexcept', as with the cases of the temporaries/copies before, that
happens outside of the function.  If the precondition verification should
be done inside the function, then either an exception (no pun intended) is
added to the language in this case, or undefined behavior is narrowed down
to anything *but* throwing an exception.  Or otherwise it could be
documented that the funcction throwing is a valid outcome and that if the
user has tagged the function 'noexcept' this would lead to termination.

AFAIK, in the standard many functions whose implementation could not
possibly throw an exception are 'noexcept(false)' if there are
preconditions to allow implementations to throw on precondition violations,
this could also be an approach: if you want precondition checking
potentially throwing, don't mark your functions 'noexcept'.  Depending on
how the contract checking goes, if the checks are lifted to the caller,
these functions could be 'noexcept' with the added preconditions.  But note
that for certain users, the ability to narrow down what undefined behavior
is in a test is important (N4075).

    David

N4075: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4075.pdf

    David

On Sat, Apr 18, 2015 at 12:22 AM, Matt Calabrese <calabrese@google.com>
wrote:

> I'm reading through N4435 and while I believe in the goals of the proposal
> I think it has a couple of unfortunate failings that need to be addressed:
>
> 1) Currently, the paper suggests treating violations in an
> implementation-specified manner, giving the example that one implementation
> may throw an exception. There are a couple of problems with this. First, by
> making the behavior implementation-specified to such an extent that some
> implementations may throw an exception, we'd be [ab]using the attribute
> facility in a way that allows programs to change behavior due to whether or
> not an attribute is handled by a compiler (I.E. a function invocation may
> be noexcept in certain compilers but not others, and on that note, what if
> you specify that a function is noexcept but with preconditions: would an
> implementation terminate when the exception would propagate, or something
> else?). This goes against the idea of attributes and could make dealing
> with such behavior very difficult, especially regarding portability.
>
> As well, a precondition violation should under no circumstance throw an
> exception, since a precondition violation is by definition a bug rather
> than a recoverable error. A precondition violation is always UB. If you
> explicitly specify some kind of well-defined behavior, such as the throwing
> of an exception, then you simply do no want that predicate to be a
> precondition. Rather, by specifying the behavior on such a violation, you
> are effectively stating that it is not a precondition, since users can now
> pass such "invalid" data, and get a specified result.
>
> 2) The paper speaks of purity with respect to contract predicates, which I
> agree is a necessity, however I believe it needs much more specific wording
> regarding exactly what it means.
>
> 3) Type invariants are described here as preconditions and postconditions
> that apply to every non-static member function. This is somewhat correct,
> but there is an important difference that goes unmentioned: the
> postcondition section states that a postcondition does not need to be met
> if the function does not return, such as if an exception propagates. This
> is proper behavior since an exception is precisely the way that an
> algorithm's inability to meet a postcondition due to, for instance,
> resource limits, is communicated back to a user. However, it is this
> property of postconditions that makes the description of an invariant as
> preconditions and postconditions that apply to all non-static member
> functions only partially correct. The key difference is that a type's
> invariants always hold even if an exception propagates, otherwise the
> function wouldn't even meet the basic exception guarantee. This is a
> subtle, but very important detail that needs to be made explicit.
>
> 4) Assuming #3 is agreed upon, this also implies that behavior for
> constructors is slightly different with respect to type invariants, since a
> constructor that throws an exception is allowed to not satisfy the
> invariants, as the type is not actually constructed.
>
> 5) The paper states that type invariants pertain to all public and
> protected non-static member functions, leaving out private member
> functions. I understand why this is the case, but I suggest an alternative:
> have type invariants pertain to all non-static member functions, including
> private ones, unless a specific member function is somehow flagged as being
> exempt from the invariant. I say this because some private member functions
> may still be written in a way that respect the type's invariants.
>
> 6) User-customization of behavior on contract violations is often useful
> in practice, even though such behavior would technically be executed when
> we are already in UB land. For instance, you can imagine systems where, if
> the process were to exit, you'd need to run some bit of code that sends a
> message to another process for safety-critical reasons. I'm not entirely
> sure what the correct solution to this is, though systems I've worked with
> have handled things by way of quick exit and at quick exit. While this
> "works," even that solution has always bugged me (pardon the pun) since the
> implication is that you're executing even more user-defined code after
> you've identified that there is some kind of UB. Such code may not behave
> as expected/make the problem even worse/delay the ending of the process,
> which risks seeing even more problems I.E. from other threads.
>
> 7) My top-level assessment is that attributes are probably not the best
> fit if it is expected that the user should be able to rely on something
> happening in the case that such a condition is detected as violated. On the
> other hand, if customization isn't considered important, attributes can at
> least be argued to be an appropriate fit... although even there I'm not
> entirely convinced. For instance, if you are to think of attributes as not
> affecting the overall visible behavior of the program, which is the
> recommendation with respect to the design of the attributes facility in
> C++, then doing something like [quick] exiting the program on a contract
> violation might not be appropriate. I say this because the contract
> specification itself is basically equivalent to a comment when seen from
> implementations that do not handle the attribute. In other words, even the
> fact that violation of the contract is UB only makes sense if the
> implementation handles the attribute. Because of this, even treating the
> contract violation as UB, in the sense that the implementation might do
> something such as exit the process, is arguably a misuse of attributes,
> since an implementation that doesn't handle the attribute may never
> actually encounter anything in the language itself that is UB.
>
> That last point might be considered overly pedantic, but I'm not sure it
> should be glossed over too lightly.
>
> Anyway, despite this blob of gripes, I really do agree with the overall
> goals of this proposal. I would just prefer to see the issues directly
> addressed.
>
> --
>
> ---
> 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/.
>

--

---
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/.

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

<div dir=3D"ltr">Just 2c:=C2=A0<br><br>Whenever you have undefined behavior=
 &quot;anything&quot; goes, an implementation should be free to throw an ex=
ception. We do this extensively in our code, in release mode precondition c=
hecks may be removed from parts or all of the program, in debug it aborts t=
he program, inside test drivers it throws an exception that identifies the =
source and can be captured and analyzed.=C2=A0 The ability of producing kno=
wn behavior through configuration of the build/run process in tests enables=
 us to verify that the components would be able to detect the invalid input=
s and abort.<br><br>I have not read the paper in detail, but there are alre=
ady cases where calling a function with the &#39;noexcept&#39; exception sp=
ecification may end up in an exception being thrown and terminate not being=
 called: copy/move constructors for arguments passed in by value and conver=
sions for arguments that need to be converted. The &#39;noexcept specificat=
ion applies to the body of the function (or the initializer list + body for=
 constructors), so there operations may already throw.=C2=A0 The next quest=
ion is where preconditions should be checked, if the code is injected into =
the caller, it would be perfectly fine to allow a precondition exception to=
 be thrown on a &#39;noexcept&#39;, as with the cases of the temporaries/co=
pies before, that happens outside of the function.=C2=A0 If the preconditio=
n verification should be done inside the function, then either an exception=
 (no pun intended) is added to the language in this case, or undefined beha=
vior is narrowed down to anything *but* throwing an exception.=C2=A0 Or oth=
erwise it could be documented that the funcction throwing is a valid outcom=
e and that if the user has tagged the function &#39;noexcept&#39; this woul=
d lead to termination.<br><br>AFAIK, in the standard many functions whose i=
mplementation could not possibly throw an exception are &#39;noexcept(false=
)&#39; if there are preconditions to allow implementations to throw on prec=
ondition violations, this could also be an approach: if you want preconditi=
on checking potentially throwing, don&#39;t mark your functions &#39;noexce=
pt&#39;.=C2=A0 Depending on how the contract checking goes, if the checks a=
re lifted to the caller, these functions could be &#39;noexcept&#39; with t=
he added preconditions.=C2=A0 But note that for certain users, the ability =
to narrow down what undefined behavior is in a test is important (N4075).<b=
r><br>=C2=A0 =C2=A0 David<br><br>N4075: <a href=3D"http://www.open-std.org/=
jtc1/sc22/wg21/docs/papers/2014/n4075.pdf">http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2014/n4075.pdf</a><br><br>=C2=A0 =C2=A0 David</div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Apr 18, 2015 a=
t 12:22 AM, Matt Calabrese <span dir=3D"ltr">&lt;<a href=3D"mailto:calabres=
e@google.com" target=3D"_blank">calabrese@google.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I&#39;m reading through =
N4435 and while I believe in the goals of the proposal I think it has a cou=
ple of unfortunate failings that need to be addressed:<div><br></div><div>1=
) Currently, the paper suggests treating violations in an implementation-sp=
ecified manner, giving the example that one implementation may throw an exc=
eption. There are a couple of problems with this. First, by making the beha=
vior implementation-specified to such an extent that some implementations m=
ay throw an exception, we&#39;d be [ab]using the attribute facility in a wa=
y that allows programs to change behavior due to whether or not an attribut=
e is handled by a compiler (I.E. a function invocation may be noexcept in c=
ertain compilers but not others, and on that note, what if you specify that=
 a function is noexcept but with preconditions: would an implementation ter=
minate when the exception would propagate, or something else?). This goes a=
gainst the idea of attributes and could make dealing with such behavior ver=
y difficult, especially regarding portability.</div><div><br></div><div>As =
well, a precondition violation should under no circumstance throw an except=
ion, since a precondition violation is by definition a bug rather than a re=
coverable error. A precondition violation is always UB. If you explicitly s=
pecify some kind of well-defined behavior, such as the throwing of an excep=
tion, then you simply do no want that predicate to be a precondition. Rathe=
r, by specifying the behavior on such a violation, you are effectively stat=
ing that it is not a precondition, since users can now pass such &quot;inva=
lid&quot; data, and get a specified result.</div><div><br></div><div>2) The=
 paper speaks of purity with respect to contract predicates, which I agree =
is a necessity, however I believe it needs much more specific wording regar=
ding exactly what it means.</div><div><br></div><div>3) Type invariants are=
 described here as preconditions and postconditions that apply to every non=
-static member function. This is somewhat correct, but there is an importan=
t difference that goes unmentioned: the postcondition section states that a=
 postcondition does not need to be met if the function does not return, suc=
h as if an exception propagates. This is proper behavior since an exception=
 is precisely the way that an algorithm&#39;s inability to meet a postcondi=
tion due to, for instance, resource limits, is communicated back to a user.=
 However, it is this property of postconditions that makes the description =
of an invariant as preconditions and postconditions that apply to all non-s=
tatic member functions only partially correct. The key difference is that a=
 type&#39;s invariants always hold even if an exception propagates, otherwi=
se the function wouldn&#39;t even meet the basic exception guarantee. This =
is a subtle, but very important detail that needs to be made explicit.</div=
><div><br></div><div>4) Assuming #3 is agreed upon, this also implies that =
behavior for constructors is slightly different with respect to type invari=
ants, since a constructor that throws an exception is allowed to not satisf=
y the invariants, as the type is not actually constructed.</div><div><br></=
div><div>5) The paper states that type invariants pertain to all public and=
 protected non-static member functions, leaving out private member function=
s. I understand why this is the case, but I suggest an alternative: have ty=
pe invariants pertain to all non-static member functions, including private=
 ones, unless a specific member function is somehow flagged as being exempt=
 from the invariant. I say this because some private member functions may s=
till be written in a way that respect the type&#39;s invariants.</div><div>=
<br></div><div>6) User-customization of behavior on contract violations is =
often useful in practice, even though such behavior would technically be ex=
ecuted when we are already in UB land. For instance, you can imagine system=
s where, if the process were to exit, you&#39;d need to run some bit of cod=
e that sends a message to another process for safety-critical reasons. I&#3=
9;m not entirely sure what the correct solution to this is, though systems =
I&#39;ve worked with have handled things by way of quick exit and at quick =
exit. While this &quot;works,&quot; even that solution has always bugged me=
 (pardon the pun) since the implication is that you&#39;re executing even m=
ore user-defined code after you&#39;ve identified that there is some kind o=
f UB. Such code may not behave as expected/make the problem even worse/dela=
y the ending of the process, which risks seeing even more problems I.E. fro=
m other threads.</div><div><br></div><div>7) My top-level assessment is tha=
t attributes are probably not the best fit if it is expected that the user =
should be able to rely on something happening in the case that such a condi=
tion is detected as violated. On the other hand, if customization isn&#39;t=
 considered important, attributes can at least be argued to be an appropria=
te fit... although even there I&#39;m not entirely convinced. For instance,=
 if you are to think of attributes as not affecting the overall visible beh=
avior of the program, which is the recommendation with respect to the desig=
n of the attributes facility in C++, then doing something like [quick] exit=
ing the program on a contract violation might not be appropriate. I say thi=
s because the contract specification itself is basically equivalent to a co=
mment when seen from implementations that do not handle the attribute. In o=
ther words, even the fact that violation of the contract is UB only makes s=
ense if the implementation handles the attribute. Because of this, even tre=
ating the contract violation as UB, in the sense that the implementation mi=
ght do something such as exit the process, is arguably a misuse of attribut=
es, since an implementation that doesn&#39;t handle the attribute may never=
 actually encounter anything in the language itself that is UB.</div><div><=
br></div><div>That last point might be considered overly pedantic, but I&#3=
9;m not sure it should be glossed over too lightly.</div><div><br></div><di=
v>Anyway, despite this blob of gripes, I really do agree with the overall g=
oals of this proposal. I would just prefer to see the issues directly addre=
ssed.</div></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
<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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
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 />

--001a11c3c1b809cff605142349a4--

.

------=_Part_216_1914907451.1429524362596
Content-Type: multipart/alternative;
 boundary="----=_Part_217_1659595015.1429524362596"

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



W dniu poniedzia=C5=82ek, 20 kwietnia 2015 09:57:48 UTC+2 u=C5=BCytkownik D=
avid=20
Rodr=C3=ADguez Ibeas napisa=C5=82:
>
> Just 2c:=20
>
> Whenever you have undefined behavior "anything" goes, an implementation=
=20
> should be free to throw an exception. We do this extensively in our code,=
=20
> in release mode precondition checks may be removed from parts or all of t=
he=20
> program, in debug it aborts the program, inside test drivers it throws an=
=20
> exception that identifies the source and can be captured and analyzed.  T=
he=20
> ability of producing known behavior through configuration of the build/ru=
n=20
> process in tests enables us to verify that the components would be able t=
o=20
> detect the invalid inputs and abort.
>
> I have not read the paper in detail, but there are already cases where=20
> calling a function with the 'noexcept' exception specification may end up=
=20
> in an exception being thrown and terminate not being called: copy/move=20
> constructors for arguments passed in by value and conversions for argumen=
ts=20
> that need to be converted. The 'noexcept specification applies to the bod=
y=20
> of the function (or the initializer list + body for constructors), so the=
re=20
> operations may already throw.  The next question is where preconditions=
=20
> should be checked, if the code is injected into the caller, it would be=
=20
> perfectly fine to allow a precondition exception to be thrown on a=20
> 'noexcept', as with the cases of the temporaries/copies before, that=20
> happens outside of the function.
>

As explained in N4160, executing preconditions in the caller does not solve=
=20
the problem of throwing from noexcept functions in the general case. For an=
=20
example and analysis, see here:=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4160.html#runtime.=
handler

Quoting from the paper: Consider:

bool positive_predicate(int i) noexcept */* requires: i > 0 */*;

bool predicate(int i) noexcept  */* requires: true */*
{
  if (i < 0)
    return negative_predicate(i);
  else
    return positive_predicate(i);
=20

Now imagine that we make a call predicate(0). Due to a bug in the function,=
=20
we call positive_predicate with a broken precondition. It doesn't help that=
=20
the throw from the handler is made from the context outside of function=20
positive_predicate, because it is still made inside the caller function=20
predicate, which is also noexcept.

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_217_1659595015.1429524362596
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu poniedzia=C5=82ek, 20 kwietnia 2015 09:57:4=
8 UTC+2 u=C5=BCytkownik David Rodr=C3=ADguez Ibeas napisa=C5=82:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Just 2c:&nbsp;<br><br>Wh=
enever you have undefined behavior "anything" goes, an implementation shoul=
d be free to throw an exception. We do this extensively in our code, in rel=
ease mode precondition checks may be removed from parts or all of the progr=
am, in debug it aborts the program, inside test drivers it throws an except=
ion that identifies the source and can be captured and analyzed.&nbsp; The =
ability of producing known behavior through configuration of the build/run =
process in tests enables us to verify that the components would be able to =
detect the invalid inputs and abort.<br><br>I have not read the paper in de=
tail, but there are already cases where calling a function with the 'noexce=
pt' exception specification may end up in an exception being thrown and ter=
minate not being called: copy/move constructors for arguments passed in by =
value and conversions for arguments that need to be converted. The 'noexcep=
t specification applies to the body of the function (or the initializer lis=
t + body for constructors), so there operations may already throw.&nbsp; Th=
e next question is where preconditions should be checked, if the code is in=
jected into the caller, it would be perfectly fine to allow a precondition =
exception to be thrown on a 'noexcept', as with the cases of the temporarie=
s/copies before, that happens outside of the function.</div></blockquote><d=
iv><br>As explained in N4160, executing preconditions in the caller does no=
t solve the problem of throwing from noexcept functions in the general case=
.. For an example and analysis, see here: <a href=3D"http://www.open-std.org=
/jtc1/sc22/wg21/docs/papers/2014/n4160.html#runtime.handler">http://www.ope=
n-std.org/jtc1/sc22/wg21/docs/papers/2014/n4160.html#runtime.handler</a><br=
><br>Quoting from the paper: Consider:<br><br><pre>bool positive_predicate(=
int i) noexcept <em>/* requires: i &gt; 0 */</em>;<br><br>bool predicate(in=
t i) noexcept  <em>/* requires: true */</em>
{
  if (i &lt; 0)
    return negative_predicate(i);
  else
    return positive_predicate(i);<br>&nbsp;</pre>

<p>Now imagine that we make a call <code>predicate(0)</code>. Due to a bug =
in the function, we call <code>positive_predicate</code> with a broken prec=
ondition. It doesn't help that the throw from the handler is made from the =
context outside of function <code>positive_predicate</code>, because it is =
still made inside the caller function  <code>predicate</code>, which is als=
o <code>noexcept</code>.</p><p>Regards,</p><p>&amp;rzej<br></p>&nbsp;</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&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 />
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_217_1659595015.1429524362596--
------=_Part_216_1914907451.1429524362596--

.

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

Right...

On Mon, Apr 20, 2015 at 11:06 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.=
com>
wrote:

> Now imagine that we make a call predicate(0). Due to a bug in the
> function, we call positive_predicate with a broken precondition. It
> doesn't help that the throw from the handler is made from the context
> outside of function positive_predicate, because it is still made inside
> the caller function predicate, which is also noexcept.
>
.... exactly in the same way that removing the exception specification from
'std::vector<T>::operator[]' would not help any of the users calling that
from a 'noexcept' function.  The behavior of the function is well defined,
there is a bug in 'predicate' that is calling 'positive_predicate' out of
context, undefined bevahior of the callee triggers an exception, the
specification in the caller turns that into a call to terminate.

I am not sure what the problem is here... undefined behavior in one part of
the program has "some" behavior, and that *will* cause the program to
behave in unexpected forms (logic falling out of the design), in this case,
calling 'terminate'.

I would expect that to be encountered during testing, while testing
'positive_predicate' you can verify (by configuring the "undefined
behavior" to mean throw) that it will fail whenever called out of contract.
While testing 'predicate' there is a clear border condition around 0 that
should have a test case.

If you want other examples of where this could break, I can provide some.
For example inside a destructor calling out of contract, even if the
destructor is 'noexcept(false)' hit while winding up... but I don't see the
point on pursuing these examples further, the program has already hit
*undefined behavior*, anything goes.

    David

--=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/.

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

<div dir=3D"ltr">Right...<br><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Mon, Apr 20, 2015 at 11:06 AM, Andrzej Krzemie=C5=84ski <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">a=
krzemi1@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div><p>Now imagine that we make a call <code>predicate(0)<=
/code>. Due to a bug in the function, we call <code>positive_predicate</cod=
e> with a broken precondition. It doesn&#39;t help that the throw from the =
handler is made from the context outside of function <code>positive_predica=
te</code>, because it is still made inside the caller function  <code>predi=
cate</code>, which is also <code>noexcept</code>.</p></div></div></blockquo=
te><div>... exactly in the same way that removing the exception specificati=
on from &#39;std::vector&lt;T&gt;::operator[]&#39; would not help any of th=
e users calling that from a &#39;noexcept&#39; function.=C2=A0 The behavior=
 of the function is well defined, there is a bug in &#39;predicate&#39; tha=
t is calling &#39;positive_predicate&#39; out of context, undefined bevahio=
r of the callee triggers an exception, the specification in the caller turn=
s that into a call to terminate.<br><br>I am not sure what the problem is h=
ere... undefined behavior in one part of the program has &quot;some&quot; b=
ehavior, and that *will* cause the program to behave in unexpected forms (l=
ogic falling out of the design), in this case, calling &#39;terminate&#39;.=
<br><br>I would expect that to be encountered during testing, while testing=
 &#39;positive_predicate&#39; you can verify (by configuring the &quot;unde=
fined behavior&quot; to mean throw) that it will fail whenever called out o=
f contract. While testing &#39;predicate&#39; there is a clear border condi=
tion around 0 that should have a test case.<br><br>If you want other exampl=
es of where this could break, I can provide some. For example inside a dest=
ructor calling out of contract, even if the destructor is &#39;noexcept(fal=
se)&#39; hit while winding up... but I don&#39;t see the point on pursuing =
these examples further, the program has already hit *undefined behavior*, a=
nything goes.<br><br>=C2=A0 =C2=A0 David</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&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 />
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 />

--001a11348c3a2981620514256a72--

.

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

One way to avoid the various undefined and nothrow problems for contracts
is to treat them as a pure compile time feature. Use static analysis and
prior post conditions to enforce all contracts at compile time. When static
analysis fails fall back to assert (or assume() for release modes) on the
client side to establish compile time truths at compile time and let the
undefined behavior occur on those explicit places.
How far has this path been explored? Is it realistic with todays static
analysis technology?
Compile time is more in the spirit of c++ and could bring something new to
contracts compared to other languages.

  / Jonas

On Mon, Apr 20, 2015 at 12:30 PM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.o=
rg>
wrote:

> Right...
>
> On Mon, Apr 20, 2015 at 11:06 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmai=
l.com>
> wrote:
>
>> Now imagine that we make a call predicate(0). Due to a bug in the
>> function, we call positive_predicate with a broken precondition. It
>> doesn't help that the throw from the handler is made from the context
>> outside of function positive_predicate, because it is still made inside
>> the caller function predicate, which is also noexcept.
>>
> ... exactly in the same way that removing the exception specification fro=
m
> 'std::vector<T>::operator[]' would not help any of the users calling that
> from a 'noexcept' function.  The behavior of the function is well defined=
,
> there is a bug in 'predicate' that is calling 'positive_predicate' out of
> context, undefined bevahior of the callee triggers an exception, the
> specification in the caller turns that into a call to terminate.
>
> I am not sure what the problem is here... undefined behavior in one part
> of the program has "some" behavior, and that *will* cause the program to
> behave in unexpected forms (logic falling out of the design), in this cas=
e,
> calling 'terminate'.
>
> I would expect that to be encountered during testing, while testing
> 'positive_predicate' you can verify (by configuring the "undefined
> behavior" to mean throw) that it will fail whenever called out of contrac=
t.
> While testing 'predicate' there is a clear border condition around 0 that
> should have a test case.
>
> If you want other examples of where this could break, I can provide some.
> For example inside a destructor calling out of contract, even if the
> destructor is 'noexcept(false)' hit while winding up... but I don't see t=
he
> point on pursuing these examples further, the program has already hit
> *undefined behavior*, anything goes.
>
>     David
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><div>One way to avoid the various undefined and nothrow pr=
oblems for contracts is to treat them as a pure compile time feature. Use s=
tatic analysis and prior post conditions to enforce all contracts at compil=
e time. When static analysis fails fall back to assert (or assume() for rel=
ease modes) on the client side to establish compile time truths at compile =
time and let the undefined behavior occur on those explicit places.</div><d=
iv>How far has this path been explored? Is it realistic with todays static =
analysis technology?</div><div>Compile time is more in the spirit of c++ an=
d could bring something new to contracts compared to other languages.</div>=
<div><br></div><div>=C2=A0 / Jonas</div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Mon, Apr 20, 2015 at 12:30 PM, David Rodr=
=C3=ADguez Ibeas <span dir=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" t=
arget=3D"_blank">dibeas@ieee.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Right...<br><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote"><span class=3D"">On Mon, Apr 20, 2015 at 11:06 AM=
, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt;<a href=3D"mailto:akrzemi1=
@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><p>Now imagine that we =
make a call <code>predicate(0)</code>. Due to a bug in the function, we cal=
l <code>positive_predicate</code> with a broken precondition. It doesn&#39;=
t help that the throw from the handler is made from the context outside of =
function <code>positive_predicate</code>, because it is still made inside t=
he caller function  <code>predicate</code>, which is also <code>noexcept</c=
ode>.</p></div></div></blockquote></span><div>... exactly in the same way t=
hat removing the exception specification from &#39;std::vector&lt;T&gt;::op=
erator[]&#39; would not help any of the users calling that from a &#39;noex=
cept&#39; function.=C2=A0 The behavior of the function is well defined, the=
re is a bug in &#39;predicate&#39; that is calling &#39;positive_predicate&=
#39; out of context, undefined bevahior of the callee triggers an exception=
, the specification in the caller turns that into a call to terminate.<br><=
br>I am not sure what the problem is here... undefined behavior in one part=
 of the program has &quot;some&quot; behavior, and that *will* cause the pr=
ogram to behave in unexpected forms (logic falling out of the design), in t=
his case, calling &#39;terminate&#39;.<br><br>I would expect that to be enc=
ountered during testing, while testing &#39;positive_predicate&#39; you can=
 verify (by configuring the &quot;undefined behavior&quot; to mean throw) t=
hat it will fail whenever called out of contract. While testing &#39;predic=
ate&#39; there is a clear border condition around 0 that should have a test=
 case.<br><br>If you want other examples of where this could break, I can p=
rovide some. For example inside a destructor calling out of contract, even =
if the destructor is &#39;noexcept(false)&#39; hit while winding up... but =
I don&#39;t see the point on pursuing these examples further, the program h=
as already hit *undefined behavior*, anything goes.<span class=3D"HOEnZb"><=
font color=3D"#888888"><br><br>=C2=A0 =C2=A0 David</font></span></div></div=
></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
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 />

--f46d0442866ccf57d8051438fca5--

.

------=_Part_1698_1018364541.1429553366277
Content-Type: multipart/alternative;
 boundary="----=_Part_1699_208173997.1429553366277"

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

On Monday, April 20, 2015 at 12:57:48 AM UTC-7, David Rodr=C3=ADguez Ibeas =
wrote:
>
> Just 2c:=20
>
> Whenever you have undefined behavior "anything" goes, an implementation=
=20
> should be free to throw an exception.
>

Of course, but if it's truly undefined behavior you should never be relying=
=20
on that in portable code, and realistically, if you aren't guaranteed that=
=20
the checking is going to happen, when do you expect the exception to be=20
thrown and when can you rely on catching it? Sometimes? In other words,=20
sometimes you can "handle" a bug? I have handle in quotes here because you=
=20
can't really handle a bug in code (I.E. a contract violation). Exceptions=
=20
can't fix "bugs" -- exceptions communicate failures in well-defined=20
programs where expected invariants still hold but where certain results=20
simply cannot be achieved. Throwing an exception is flat out incorrect to=
=20
do on a precondition violation because such a violation is indicative=20
either of expected invariants being discovered to not hold in an otherwise=
=20
well-formed program, or in a program where UB exists.

So yeah, an exception can be thrown in UB land because anything can happen=
=20
there, but implementations should not be encouraged to do so, and since it=
=20
happens in UB territory, its relation to noexcept and whether or not a user=
=20
can reliably catch the exception is a non-issue.=20

We do this extensively in our code, in release mode precondition checks may=
=20
> be removed from parts or all of the program, in debug it aborts the=20
> program, inside test drivers it throws an exception that identifies the=
=20
> source and can be captured and analyzed.  The ability of producing known=
=20
> behavior through configuration of the build/run process in tests enables =
us=20
> to verify that the components would be able to detect the invalid inputs=
=20
> and abort.
>

This can also be accomplished without exceptions.

I have not read the paper in detail, but there are already cases where=20
> calling a function with the 'noexcept' exception specification may end up=
=20
> in an exception being thrown and terminate not being called: copy/move=20
> constructors for arguments passed in by value and conversions for argumen=
ts=20
> that need to be converted.
>

There is nothing violating a noexcept specification in the pass-by-value=20
case that you describe. Using the noexcept operator or traits would=20
correctly tell you that an exception can be thrown. There is just confusion=
=20
from people who read the declaration and don't understand the language well=
=20
enough to understand that the construction of the argument can throw an=20
exception.

The 'noexcept specification applies to the body of the function (or the=20
> initializer list + body for constructors), so there operations may alread=
y=20
> throw.  The next question is where preconditions should be checked, if th=
e=20
> code is injected into the caller, it would be perfectly fine to allow a=
=20
> precondition exception to be thrown on a 'noexcept', as with the cases of=
=20
> the temporaries/copies before, that happens outside of the function.
>

It doesn't at all matter where the throw happens because at that point you=
=20
have a bug and are either in language-level UB land, or are in an unhandled=
=20
program state due to a program's expected invariants not holding (I.E. the=
=20
programmer made some kind of mistake not directly involving UB). If control=
=20
would lead to undefined behavior in a program, quite literally any part of=
=20
that program can have unexpected results, including parts in code that=20
appear to happen "before" the operation that has UB. Stating anything about=
=20
how exceptions should behave here in UB territory is simply a mistake=20
because at the point that you already can't rely on anything at all, in=20
practice meaning that you can't assume that the exception will propagate=20
properly or that you can properly catch the exception.

It simply needs to be understood that a contract violation such as a=20
precondition failure is UB.

If the precondition verification should be done inside the function, then=
=20
> either an exception (no pun intended) is added to the language in this=20
> case, or undefined behavior is narrowed down to anything *but* throwing a=
n=20
> exception.
>

This is silly. Undefined is undefined is undefined. Don't violate such a=20
contract. It's like dividing an integer by zero or writing to a=20
dereferenced null pointer.

--=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_1699_208173997.1429553366277
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, April 20, 2015 at 12:57:48 AM UTC-7, David Rodr=
=C3=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, =
204); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr">Just 2=
c:&nbsp;<br><br>Whenever you have undefined behavior "anything" goes, an im=
plementation should be free to throw an exception.</div></blockquote><div><=
br></div><div>Of course, but if it's truly undefined behavior you should ne=
ver be relying on that in portable code, and realistically, if you aren't g=
uaranteed that the checking is going to happen, when do you expect the exce=
ption to be thrown and when can you rely on catching it? Sometimes? In othe=
r words, sometimes you can "handle" a bug? I have handle in quotes here bec=
ause you can't really handle a bug in code (I.E. a contract violation). Exc=
eptions can't fix "bugs" -- exceptions communicate failures in well-defined=
 programs where expected invariants still hold but where certain results si=
mply cannot be achieved. Throwing an exception is flat out incorrect to do =
on a precondition violation because such a violation is indicative either o=
f expected invariants being discovered to not hold in an otherwise well-for=
med program, or in a program where UB exists.</div><div><br></div><div>So y=
eah, an exception can be thrown in UB land because anything can happen ther=
e, but implementations should not be encouraged to do so, and since it happ=
ens in UB territory, its relation to noexcept and whether or not a user can=
 reliably catch the exception is a non-issue.&nbsp;</div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-l=
eft-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: s=
olid; padding-left: 1ex;"><div dir=3D"ltr"> We do this extensively in our c=
ode, in release mode precondition checks may be removed from parts or all o=
f the program, in debug it aborts the program, inside test drivers it throw=
s an exception that identifies the source and can be captured and analyzed.=
&nbsp; The ability of producing known behavior through configuration of the=
 build/run process in tests enables us to verify that the components would =
be able to detect the invalid inputs and abort.<br></div></blockquote><div>=
<br></div><div>This can also be accomplished without exceptions.</div><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-=
left-style: solid; padding-left: 1ex;"><div dir=3D"ltr">I have not read the=
 paper in detail, but there are already cases where calling a function with=
 the 'noexcept' exception specification may end up in an exception being th=
rown and terminate not being called: copy/move constructors for arguments p=
assed in by value and conversions for arguments that need to be converted.<=
/div></blockquote><div><br></div><div>There is nothing violating a noexcept=
 specification in the pass-by-value case that you describe. Using the noexc=
ept operator or traits would correctly tell you that an exception can be th=
rown. There is just confusion from people who read the declaration and don'=
t understand the language well enough to understand that the construction o=
f the argument can throw an exception.</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1p=
x; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding=
-left: 1ex;"><div dir=3D"ltr">The 'noexcept specification applies to the bo=
dy of the function (or the initializer list + body for constructors), so th=
ere operations may already throw.&nbsp; The next question is where precondi=
tions should be checked, if the code is injected into the caller, it would =
be perfectly fine to allow a precondition exception to be thrown on a 'noex=
cept', as with the cases of the temporaries/copies before, that happens out=
side of the function.</div></blockquote><div><br></div><div>It doesn't at a=
ll matter where the throw happens because at that point you have a bug and =
are either in language-level UB land, or are in an unhandled program state =
due to a program's expected invariants not holding (I.E. the programmer mad=
e some kind of mistake not directly involving UB). If control would lead to=
 undefined behavior in a program, quite literally any part of that program =
can have unexpected results, including parts in code that appear to happen =
"before" the operation that has UB. Stating anything about how exceptions s=
hould behave here in UB territory is simply a mistake because at the point =
that you already can't rely on anything at all, in practice meaning that yo=
u can't assume that the exception will propagate properly or that you can p=
roperly catch the exception.</div><div><br></div><div>It simply needs to be=
 understood that a contract violation such as a precondition failure is UB.=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 20=
4); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr">If the p=
recondition verification should be done inside the function, then either an=
 exception (no pun intended) is added to the language in this case, or unde=
fined behavior is narrowed down to anything *but* throwing an exception.</d=
iv></blockquote><div><br></div><div>This is silly. Undefined is undefined i=
s undefined. Don't violate such a contract. It's like dividing an integer b=
y zero or writing to a dereferenced null pointer.</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&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 />
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_1699_208173997.1429553366277--
------=_Part_1698_1018364541.1429553366277--

.

------=_Part_2358_987887260.1429413004399
Content-Type: multipart/alternative;
 boundary="----=_Part_2359_1225103863.1429413004399"

------=_Part_2359_1225103863.1429413004399
Content-Type: text/plain; charset=UTF-8

On Saturday, April 18, 2015 at 9:14:36 PM UTC-4, Vicente J. Botet Escriba
wrote:
>
> I don't believe neither that we need to remove the noexcept of a narrow
> function, just because the compiler could throw an exception if the
> conditions are violated. Extrapolating this would mean that any function
> that can violate the invariants cannot be noexcept. This would imply that
> the user wouldn't add invariants when noexcept must be used.
>

I know I've said this before, but I would really discourage vendors from
throwing exceptions here. If you have a contract violation then there is a
bug, plain and simple, often because higher-level invariants do not
actually hold. By throwing an exception and unraveling the stack, all you
are doing is executing more code that may be dependent on such invariants.
If an implementation happens to notice that a contract has been violated,
it should ideally be executing minimal user-code after that point
(preferably none at all, not even destructors of stack-allocated nor
destructors of global objects), and it should exit the process.

The whole noexcept thing should simply not be an issue and we should avoid
giving attention to it.

--

---
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_2359_1225103863.1429413004399
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, April 18, 2015 at 9:14:36 PM UTC-4, Vicente J=
.. Botet Escriba wrote:&nbsp;<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv text=3D"#000000" bgcolor=3D"#FFFFFF">I don't believe neither that we nee=
d to remove the noexcept of a
    narrow function, just because the compiler could throw an exception
    if the conditions are violated. Extrapolating this would mean that
    any function that can violate the invariants cannot be noexcept.
    This would imply that the user wouldn't add invariants when noexcept
    must be used.<br></div></blockquote><div><br></div><div>I know I've sai=
d this before, but I would really discourage vendors from throwing exceptio=
ns here. If you have a contract violation then there is a bug, plain and si=
mple, often because higher-level invariants do not actually hold. By throwi=
ng an exception and unraveling the stack, all you are doing is executing mo=
re code that may be dependent on such invariants. If an implementation happ=
ens to notice that a contract has been violated, it should ideally be execu=
ting minimal user-code after that point (preferably none at all, not even d=
estructors of stack-allocated nor destructors of global objects), and it sh=
ould exit the process.</div><div><br></div><div>The whole noexcept thing sh=
ould simply not be an issue and we should avoid giving attention to it.</di=
v></div>

<p></p>

-- <br />
<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+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_2359_1225103863.1429413004399--
------=_Part_2358_987887260.1429413004399--

.

------=_Part_3033_1217886518.1429474306032
Content-Type: multipart/alternative;
 boundary="----=_Part_3034_1352068469.1429474306032"

------=_Part_3034_1352068469.1429474306032
Content-Type: text/plain; charset=UTF-8

On Sunday, April 19, 2015 at 2:32:24 PM UTC-4, Zhihao Yuan wrote:
>
> My big complain about class invariant is that it does not
> work on ADL interfaces.  Member functions contribute to
> only one part of class interfaces.
>

True. And it's also important to note that a single function that modifies
multiple objects during its execution, whether it's a member function or a
non-member function, needs to respect the invariants of each of those
objects that are involved.

In other words, any function that takes an object by reference needs to
respect the invariants of that object such that when the overall function
returns/propagates an exception, the invariants hold. I'd argue that this
should always be true unless a function explicitly states otherwise on a
per parameter basis -- similar to what I suggested for private member
functions.

--

---
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_3034_1352068469.1429474306032
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, April 19, 2015 at 2:32:24 PM UTC-4, Zhihao Yuan=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">My big complain about c=
lass invariant is that it does not
<br>work on ADL interfaces. &nbsp;Member functions contribute to
<br>only one part of class interfaces.
<br></blockquote><div><br></div><div>True. And it's also important to note =
that a single function that modifies multiple objects during its execution,=
 whether it's a member function or a non-member function, needs to respect =
the invariants of each of those objects that are involved.</div><div><br></=
div><div>In other words, any function that takes an object by reference nee=
ds to respect the invariants of that object such that when the overall func=
tion returns/propagates an exception, the invariants hold. I'd argue that t=
his should always be true unless a function explicitly states otherwise on =
a per parameter basis -- similar to what I suggested for private member fun=
ctions.</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&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 />
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_3034_1352068469.1429474306032--
------=_Part_3033_1217886518.1429474306032--

.

------=_Part_837_837285055.1429873296518
Content-Type: multipart/alternative;
 boundary="----=_Part_838_1937064241.1429873296518"

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



W dniu wtorek, 21 kwietnia 2015 11:51:17 UTC+2 u=C5=BCytkownik Jonas Persso=
n=20
napisa=C5=82:
>
> One way to avoid the various undefined and nothrow problems for contracts=
=20
> is to treat them as a pure compile time feature. Use static analysis and=
=20
> prior post conditions to enforce all contracts at compile time. When stat=
ic=20
> analysis fails fall back to assert (or assume() for release modes) on the=
=20
> client side to establish compile time truths at compile time and let the=
=20
> undefined behavior occur on those explicit places.
> How far has this path been explored? Is it realistic with todays static=
=20
> analysis technology?
> Compile time is more in the spirit of c++ and could bring something new t=
o=20
> contracts compared to other languages.
>

This is what n4160=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4160.html> tried=
=20
to explore "in theory". There exist static analyzers for detecting a=20
potential UB (Undefined Behavior). The hope is that if we allowed the=20
feature for defining more UB in a controlled manner, this could be taken=20
into account by UB analyzers. But as I am not familiar with how such tools=
=20
are written, this remains just a theory. Personally I would be satisfied if=
=20
I were able only to declare my preconditions in a type-checked manner, as=
=20
information to other programmers. But people's attention seems to shift to=
=20
run-time response, which to me appears of no use in performance-critical=20
applications.

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>W dniu wtorek, 21 kwietnia 2015 11:51:17 UTC+2 u=
=C5=BCytkownik Jonas Persson 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>One way to avoid the various undefined an=
d nothrow problems for contracts is to treat them as a pure compile time fe=
ature. Use static analysis and prior post conditions to enforce all contrac=
ts at compile time. When static analysis fails fall back to assert (or assu=
me() for release modes) on the client side to establish compile time truths=
 at compile time and let the undefined behavior occur on those explicit pla=
ces.</div><div>How far has this path been explored? Is it realistic with to=
days static analysis technology?</div><div>Compile time is more in the spir=
it of c++ and could bring something new to contracts compared to other lang=
uages.</div></div></blockquote><div><br>This is what <a href=3D"http://www.=
open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4160.html">n4160</a> tried to=
 explore "in theory". There exist static analyzers for detecting a potentia=
l UB (Undefined Behavior). The hope is that if we allowed the feature for d=
efining more UB in a controlled manner, this could be taken into account by=
 UB analyzers. But as I am not familiar with how such tools are written, th=
is remains just a theory. Personally I would be satisfied if I were able on=
ly to declare my preconditions in a type-checked manner, as information to =
other programmers. But people's attention seems to shift to run-time respon=
se, which to me appears of no use in performance-critical applications.<br>=
<br>Regards,<br>&amp;rzej<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
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_838_1937064241.1429873296518--
------=_Part_837_837285055.1429873296518--

.

This is a multi-part message in MIME format.
--------------090904070407070901070705
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 24/04/15 13:01, Andrzej Krzemie=C5=84ski a =C3=A9crit :
>
>
> W dniu wtorek, 21 kwietnia 2015 11:51:17 UTC+2 u=C5=BCytkownik Jonas=20
> Persson napisa=C5=82:
>
>     One way to avoid the various undefined and nothrow problems for
>     contracts is to treat them as a pure compile time feature. Use
>     static analysis and prior post conditions to enforce all contracts
>     at compile time. When static analysis fails fall back to assert
>     (or assume() for release modes) on the client side to establish
>     compile time truths at compile time and let the undefined behavior
>     occur on those explicit places.
>     How far has this path been explored? Is it realistic with todays
>     static analysis technology?
>     Compile time is more in the spirit of c++ and could bring
>     something new to contracts compared to other languages.
>
>
> This is what n4160=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4160.html>=20
> tried to explore "in theory". There exist static analyzers for=20
> detecting a potential UB (Undefined Behavior). The hope is that if we=20
> allowed the feature for defining more UB in a controlled manner, this=20
> could be taken into account by UB analyzers. But as I am not familiar=20
> with how such tools are written, this remains just a theory.=20
> Personally I would be satisfied if I were able only to declare my=20
> preconditions in a type-checked manner, as information to other=20
> programmers. But people's attention seems to shift to run-time=20
> response, which to me appears of no use in performance-critical=20
> applications.
>
The particular case of the move operation could be managed by compile=20
time pre/post conditions as suggested by Andrzej. Andzej suggest the use=20
of properties as e;g.

template <typename T>
property bool is_partially_formed (T const&);


T&& move(T& t) [[post: is_partially_formed(t) ]]
X& X::X(const& X x) [[pre: ! is_partially_formed(x) post: !=20
is_partially_formed(*this) ]]

Any other operation than destruction and assignment

R X::f() [[pre: ! is_partially_formed(*this) ]]

X x; // doesn't have property is_partially_formed yet.
X y =3D std::move(x); // x has property is_partially_formed now.
x =3D makeX(); // x doesn't have property is_partially_formed anymore

Could properties be used in other contexts than the one to express a=20
contract?

Andrzej please, let me know if I understood well your proposal.

Vicente

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 24/04/15 13:01, Andrzej Krzemie=C5=84=
ski
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:e86b9742-32bb-496d-8f12-62acceaeb1d3@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        W dniu wtorek, 21 kwietnia 2015 11:51:17 UTC+2 u=C5=BCytkownik Jona=
s
        Persson 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>One way to avoid the various undefined and nothrow
              problems for contracts is to treat them as a pure compile
              time feature. Use static analysis and prior post
              conditions to enforce all contracts at compile time. When
              static analysis fails fall back to assert (or assume() for
              release modes) on the client side to establish compile
              time truths at compile time and let the undefined behavior
              occur on those explicit places.</div>
            <div>How far has this path been explored? Is it realistic
              with todays static analysis technology?</div>
            <div>Compile time is more in the spirit of c++ and could
              bring something new to contracts compared to other
              languages.</div>
          </div>
        </blockquote>
        <div><br>
          This is what <a moz-do-not-send=3D"true"
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4160.html"=
>n4160</a>
          tried to explore "in theory". There exist static analyzers for
          detecting a potential UB (Undefined Behavior). The hope is
          that if we allowed the feature for defining more UB in a
          controlled manner, this could be taken into account by UB
          analyzers. But as I am not familiar with how such tools are
          written, this remains just a theory. Personally I would be
          satisfied if I were able only to declare my preconditions in a
          type-checked manner, as information to other programmers. But
          people's attention seems to shift to run-time response, which
          to me appears of no use in performance-critical applications.<br>
          <br>
        </div>
      </div>
    </blockquote>
    The particular case of the move operation could be managed by
    compile time pre/post conditions as suggested by Andrzej. Andzej
    suggest the use of properties as e;g.<br>
    <br>
    template &lt;typename T&gt;<br>
    property bool is_partially_formed (T const&amp;);<br>
    <br>
    <br>
    T&amp;&amp; move(T&amp; t) [[post: is_partially_formed(t) ]]<br>
    X&amp; X::X(const&amp; X x) [[pre: ! is_partially_formed(x) post: !
    is_partially_formed(*this) ]]<br>
    <br>
    Any other operation than destruction and assignment<br>
    <br>
    R X::f() [[pre: ! is_partially_formed(*this) ]]<br>
    <br>
    X x; // doesn't have property is_partially_formed yet.<br>
    X y =3D std::move(x); // x has property is_partially_formed now.<br>
    x =3D makeX(); // x doesn't have property is_partially_formed anymore<b=
r>
    <br>
    Could properties be used in other contexts than the one to express a
    contract?<br>
    <br>
    Andrzej please, let me know if I understood well your proposal.<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
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 />

--------------090904070407070901070705--

.

------=_Part_1255_1073367899.1429895299540
Content-Type: multipart/alternative;
 boundary="----=_Part_1256_1231643693.1429895299540"

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



W dniu pi=C4=85tek, 24 kwietnia 2015 18:48:30 UTC+2 u=C5=BCytkownik Vicente=
 J. Botet=20
Escriba napisa=C5=82:
>
>  Le 24/04/15 13:01, Andrzej Krzemie=C5=84ski a =C3=A9crit :
> =20
>
>
> W dniu wtorek, 21 kwietnia 2015 11:51:17 UTC+2 u=C5=BCytkownik Jonas Pers=
son=20
> napisa=C5=82:=20
>>
>>  One way to avoid the various undefined and nothrow problems for=20
>> contracts is to treat them as a pure compile time feature. Use static=20
>> analysis and prior post conditions to enforce all contracts at compile=
=20
>> time. When static analysis fails fall back to assert (or assume() for=20
>> release modes) on the client side to establish compile time truths at=20
>> compile time and let the undefined behavior occur on those explicit plac=
es.
>> How far has this path been explored? Is it realistic with todays static=
=20
>> analysis technology?
>> Compile time is more in the spirit of c++ and could bring something new=
=20
>> to contracts compared to other languages.
>> =20
>
> This is what n4160=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4160.html>=20
> tried to explore "in theory". There exist static analyzers for detecting =
a=20
> potential UB (Undefined Behavior). The hope is that if we allowed the=20
> feature for defining more UB in a controlled manner, this could be taken=
=20
> into account by UB analyzers. But as I am not familiar with how such tool=
s=20
> are written, this remains just a theory. Personally I would be satisfied =
if=20
> I were able only to declare my preconditions in a type-checked manner, as=
=20
> information to other programmers. But people's attention seems to shift t=
o=20
> run-time response, which to me appears of no use in performance-critical=
=20
> applications.
>
>   The particular case of the move operation could be managed by compile=
=20
> time pre/post conditions as suggested by Andrzej. Andzej suggest the use =
of=20
> properties as e;g.
>
> template <typename T>
> property bool is_partially_formed (T const&);
>
>
> T&& move(T& t) [[post: is_partially_formed(t) ]]
> X& X::X(const& X x) [[pre: ! is_partially_formed(x) post: !=20
> is_partially_formed(*this) ]]
>
> Any other operation than destruction and assignment
>
> R X::f() [[pre: ! is_partially_formed(*this) ]]
>
> X x; // doesn't have property is_partially_formed yet.
> X y =3D std::move(x); // x has property is_partially_formed now.
> x =3D makeX(); // x doesn't have property is_partially_formed anymore
>
> Could properties be used in other contexts than the one to express a=20
> contract?
>
> Andrzej please, let me know if I understood well your proposal.
>

Yes, basically this is an idea. The difference from "run-time" proposals is=
=20
that the body of the pre-/post-condition is formal enough to be=20
machine-analyzed or type-checked but is not necessarily "executable". You=
=20
use it to trace the "property" of the object(s) throughout their life=20
times. For the system to be complete you also need a way to describe=20
relations between properties, like "being positive implies being=20
non-neative".

Such properties are akin to concept axioms. I guess tools could use them=20
for seeking optimization opportunities, e.g.: when a type is sorted, it is=
=20
allowed for the machine to substitute a binary search for a linear search.

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 24 kwietnia 2015 18:48:30 UTC+=
2 u=C5=BCytkownik Vicente J. Botet Escriba napisa=C5=82:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 24/04/15 13:01, Andrzej Krzemie=C5=84ski
      a =C3=A9crit&nbsp;:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        W dniu wtorek, 21 kwietnia 2015 11:51:17 UTC+2 u=C5=BCytkownik Jona=
s
        Persson napisa=C5=82:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div dir=3D"ltr">
            <div>One way to avoid the various undefined and nothrow
              problems for contracts is to treat them as a pure compile
              time feature. Use static analysis and prior post
              conditions to enforce all contracts at compile time. When
              static analysis fails fall back to assert (or assume() for
              release modes) on the client side to establish compile
              time truths at compile time and let the undefined behavior
              occur on those explicit places.</div>
            <div>How far has this path been explored? Is it realistic
              with todays static analysis technology?</div>
            <div>Compile time is more in the spirit of c++ and could
              bring something new to contracts compared to other
              languages.</div>
          </div>
        </blockquote>
        <div><br>
          This is what <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2014/n4160.html" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.or=
g%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4160.html\46sa\75D\46sntz\=
0751\46usg\75AFQjCNGHeU1o-fWI-4snJFGCW8gOCtqisA';return true;" onclick=3D"t=
his.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fj=
tc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4160.html\46sa\75D\46sntz\0751\=
46usg\75AFQjCNGHeU1o-fWI-4snJFGCW8gOCtqisA';return true;">n4160</a>
          tried to explore "in theory". There exist static analyzers for
          detecting a potential UB (Undefined Behavior). The hope is
          that if we allowed the feature for defining more UB in a
          controlled manner, this could be taken into account by UB
          analyzers. But as I am not familiar with how such tools are
          written, this remains just a theory. Personally I would be
          satisfied if I were able only to declare my preconditions in a
          type-checked manner, as information to other programmers. But
          people's attention seems to shift to run-time response, which
          to me appears of no use in performance-critical applications.<br>
          <br>
        </div>
      </div>
    </blockquote>
    The particular case of the move operation could be managed by
    compile time pre/post conditions as suggested by Andrzej. Andzej
    suggest the use of properties as e;g.<br>
    <br>
    template &lt;typename T&gt;<br>
    property bool is_partially_formed (T const&amp;);<br>
    <br>
    <br>
    T&amp;&amp; move(T&amp; t) [[post: is_partially_formed(t) ]]<br>
    X&amp; X::X(const&amp; X x) [[pre: ! is_partially_formed(x) post: !
    is_partially_formed(*this) ]]<br>
    <br>
    Any other operation than destruction and assignment<br>
    <br>
    R X::f() [[pre: ! is_partially_formed(*this) ]]<br>
    <br>
    X x; // doesn't have property is_partially_formed yet.<br>
    X y =3D std::move(x); // x has property is_partially_formed now.<br>
    x =3D makeX(); // x doesn't have property is_partially_formed anymore<b=
r>
    <br>
    Could properties be used in other contexts than the one to express a
    contract?<br>
    <br>
    Andrzej please, let me know if I understood well your proposal.<br></di=
v></blockquote><div><br>Yes, basically this is an idea. The difference from=
 "run-time" proposals is that the body of the pre-/post-condition is formal=
 enough to be machine-analyzed or type-checked but is not necessarily "exec=
utable". You use it to trace the "property" of the object(s) throughout the=
ir life times. For the system to be complete you also need a way to describ=
e relations between properties, like "being positive implies being non-neat=
ive".<br><br>Such properties are akin to concept axioms. I guess tools coul=
d use them for seeking optimization opportunities, e.g.: when a type is sor=
ted, it is allowed for the machine to substitute a binary search for a line=
ar search.<br><br>Regards,<br>&amp;rzej<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
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_1256_1231643693.1429895299540--
------=_Part_1255_1073367899.1429895299540--

.

Hello,

On Fri, Apr 24, 2015 at 2:08 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>
>
> W dniu pi=C4=85tek, 24 kwietnia 2015 18:48:30 UTC+2 u=C5=BCytkownik Vicen=
te J. Botet
> Escriba napisa=C5=82:
>>

[snip]

>> template <typename T>
>> property bool is_partially_formed (T const&);
>>
>> T&& move(T& t) [[post: is_partially_formed(t) ]]
>> X& X::X(const& X x) [[pre: ! is_partially_formed(x) post: !
>> is_partially_formed(*this) ]]
>>
>> Any other operation than destruction and assignment
>>
>> R X::f() [[pre: ! is_partially_formed(*this) ]]
>>
>> X x; // doesn't have property is_partially_formed yet.
>> X y =3D std::move(x); // x has property is_partially_formed now.
>> x =3D makeX(); // x doesn't have property is_partially_formed anymore
>>
>> Could properties be used in other contexts than the one to express a
>> contract?
>>
>> Andrzej please, let me know if I understood well your proposal.
>
> Yes, basically this is an idea. The difference from "run-time" proposals =
is
> that the body of the pre-/post-condition is formal enough to be
> machine-analyzed or type-checked but is not necessarily "executable". You
> use it to trace the "property" of the object(s) throughout their life tim=
es.
> For the system to be complete you also need a way to describe relations
> between properties, like "being positive implies being non-neative".
>
> Such properties are akin to concept axioms. I guess tools could use them =
for
> seeking optimization opportunities, e.g.: when a type is sorted, it is
> allowed for the machine to substitute a binary search for a linear search=
..

I like this idea very much. A implementation could even use "tag dispatchin=
g"
or SFINAE on properties where one can be evaluated at compile-time.

Still, a proposal needs to propose syntax for these problems. And I
like the property syntax. And if the syntax could be easily
extractable as a clang-tool, I would be very willing to try something,
maybe using Isabelle as a proof assistant.

Maybe attributes can be used as an experimentation, but I doubt it
the commitee would be willlling to accept creating UB through
attributes.

I like the property and axiom way and I think we should have a
framework that allows for proving correctness. Achieving that,
optimizations are easier. But not the other way around.
We could implement properties with attributes.

template <typename I>
bool valid_range (I first, I last) [[property]];

And, I think we could write some axioms as well using properties:

template <typename I>
bool symetric (I x, I y) [[property]] [[post: x + y <=3D> y + x]];

And we could include these in concepts:

concept Container<typename C, typename I>
{
  bool is_empty (C c) [[property]]
   [[post: !is_non_empty(c)
             && c.empty()
             && c.size() =3D=3D 0
  ]];
  bool is_non_empty (C c) [[property]]
  [[post: !is_empty(c)
            && !c.empty()
            && c.size() !=3D 0
  ]];
};

Also, we might need to be able to create restricted
variable-constants (auxiliary?) in pre so we can use in
post-conditions. N2887 uses parameters for creating variables.
Properties, OTH, apply to constant-variables and not implicitly
\forall.  One possibility might be to have properties with
intrinsic semantics:

template <typename V, unsigned int>
V forall() [[property]];

template <typename V, unsigned int>
V exists() [[property]];

template <typename I, typename I>
bool sort(I first, I last)
  [[pre: valid_range(first, last)
         && valid_range(first, forall<I, 0>())
         && valid_range(forall<I, 0>(), last)
  ]]
  [[post: forall<I, 0>() =3D=3D last
          || *forall<I, 0> < *std::next(forall<I, 0>)
  ]];

Anyway, these are just ideas. The last one not my very best,
a new syntax would be way better.

> Regards,
> &rzej

Kind regards,
--=20
Felipe Magno de Almeida

--=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/.

.