<html>
<head>
 <meta charset="UTF-8">
<title>Support for contract based programming in C++</title>
<style type="text/css">
blockquote.std { color: #000000; background-color: #F1F1F1;
                 border: 1px solid #D1D1D1;
                 padding-left: 0.5em; padding-right: 0.5em; }
blockquote.stddel { text-decoration: line-through;
                    color: #000000; background-color: #FFA0A0;
                    border: 1px solid #ECD7EC;
                    padding-left: 0.5em; padding-right: 0.5em; }

blockquote.stdins { color: #000000; background-color: #A0FFA0;
                    border: 1px solid #B3EBB3; padding: 0.5em; }

blockquote.stdrepl { color: #000000; background-color: #FFFFA0;
                    border: 1px solid #EBEBB3; padding: 0.5em; }


ins { background-color:#A0FFA0; text-decoration: none }
del { background-color:#FFA0A0; text-decoration: line-through; }
#hidedel:checked ~ * del, #hidedel:checked ~ * del * { display:none; visibility:hidden }

tab { padding-left: 4em; }
tab3 { padding-left: 3em; }
</style>
</head>
<body>
<p align=right>
Document number:<b>P0542R1</b><br/>
Date: <b>2017-06-16</b><br/>
Audience: <b>Library Evolution Working Group</b>
<p align=right>
<br/>Reply to: J. Daniel Garcia (josedaniel.garcia@uc3m.es)
</p>

<BR><BR><HR>

<h1>Support for contract based programming in C++</h1>

<h2>G. Dos Reis, J. D. Garcia, J. Lakos, A. Meredith, N. Myers, B. Stroustrup</h2>

<h2>1. Introduction</h2>

This paper is based on P0380 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf">P0380R1</a> <a href="#bib-contracts-design">[1]</a>).
All changes are relative to latest working draft (<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/n4618.pdf">N4618</a> <a href="#bib-cpp-draft">[2]</a>).

<h2>2. Summary of wording</h2>

<h3>2.1. A new attributes syntax</h3>

<p>
To simplify the way that contracts are specified, and in line with our previous design paper,
we propose a new syntax that may be used for attributes.
</p>

<p>
We propose this new syntax to be usable by attributes taking a single argument, which is a valid expression.

<pre><b>
[[contract-attribute: expression]]
</b></pre>
where a <i>contract-attribute</i> is one of the following: <tt><b>expects</b></tt>, <tt><b>ensures</b></tt>, <tt><b>assert</b></tt>.
</p>

<p>
To avoid confusion, 
only the colon syntax for attributes is permitted in contract specifications
</p>

<p>
We also needed to support the idea of assertion levels needed by contracts.
For this reason, we have introduced the concept of an attribute modifier that may appear after the attribute token itself.

<pre><b>
[[contract-attribute modifier: expression]]
</b></pre>

In this way we may specify contracts with assertion levels easily.
We require that each attribute using the new proposed attribute syntax explicitly lists its accepted modifiers (if any).
</p>

<p>
Finally, we needed to introduce the ability to define the return value to be used in postconditions.
We allow, that an attribute lists an identifier which is associated with the return value of a function.
<pre><b>
[[contract-attribute modifier identifier: expression]
</b></pre>
</p>

<p>
With all this changes we can easily specify a contract:
<pre><b>
int f(int x)
  [[expects audit: x>0]]
  [[ensures axiom res: res>1]];

void g() {
  int x = f(5);
  int y = f(12);
  //...
  [[assert: x+y>0]]
</b></pre>
</p>

<p>
Note that while <tt><b>assert(expression)</b></tt> would expand as a function-like macro
with the appropriate header, <tt><b>assert:</b></tt> is not a function-like invocation, so
does not expand.
</p>


<h3>2.2. Functions versus function types</h3>

The current standard establishes a distinction between an attribute applied to a function and to the function type
(the normative text uses the form "appertain to function type").
With that approach there would be a difference betweeen the following cases:

<pre><b>
[[attribute]] void f(); // Attribute applied to function
void f [[attribute]] (); // Attribute applied to function
void f() [[attribute]]; // Attribute applied to function type
</b></pre>

However, we know of no example where an attribute is effectively used to annotate the function type.
Besides, the current status makes it difficult to annotate functions with preconditions and postconditions.
Consequently, in this paper we propose that attributes at the end of a function declaration apply to the 
function itself.

<pre><b>
[[attribute]] void f(); // Attribute applied to function
void f [[attribute]] (); // Attribute applied to function
void f() [[attribute]]; // Attribute applied to function
</b></pre>

Additionally, this solution solves the issue of being able to use attributes on lambda expressions (see Core issue 2097).

<h3>2.3 Contracts repetition</h3>

<p>
We require that any redeclaration of a function either has the contract or completely omits it.
<pre><b>
int f(int x) 
  [[expects: x>0]]
  [[ensures r: r>0]];

int f(int x); // OK. No contract.

int f(int x)
  [[expects: x>=0]]; // Error missing ensures and different expects condition

int f(int x)
  [[expects: x>0]]
  [[ensures r: r>0]]; //OK. Same contract.
</b></pre>
</p>

<p>
Different argument names in redeclaration would be usually considered irrelevant.
<pre><b>
int f(int x) 
  [[expects: x>0]]
  [[ensures r: r>0]];

int f(int y)
  [[expects: y>0]]
  [[ensures z: z>0]]; // Should be OK
</b></pre>
</p>

Consequently, we require that contracts are odr-identical in redeclarations, 
allowing for argument names variation.


<h3>2.4 Structured bindings and postconditions</h3>

<p>
One might imagine using structured bindings in postconditions:
<pre><b>
std::tuple<int,string> f() 
  [[ensures [x,y]: x>0 && y.size()>0]];
</b></pre>
</p>

<p>
However, we decided that this is something that might be considered for a
future version. The same effect can be achieved currently as follows:

<pre><b>
std::tuple<int,string> f() 
  [[ensures r: get<0>(r)>0 && get<1>(r).size()>0]];
</b></pre>
</p>

<h3>2.5 Information of contract_violation</h3>

<p>
The information in <tt><b>contract_violation</b></tt> could be partially represented
by a <tt><b>source_location</b></tt> object, from the Library Fundamentals V2
Technical Specification.
</p>

<p>
However, we defer this decision for a future version of this proposal.
</p>

<h3>2.6 Name lookup of contracts</h3>

<p>
Name lookup resolution in contracts may interact with the use of different build modes.
</p>

<p>
There are two answers here. The first one would be to make resolution dependent on the
current build mode, requiring that only the contracts that would be evaluated in the
current build mode need to parse correctly and pass the name lookup.
</p>

<p>
A second solution would be to make name lookup independent of build mode. In that case,
all contracts would be required to pass name lookup independently of their assertion level.
We have selected this second solution.
</p>

<h3>2.7 Identical contracts</h3>

<p>
We are also requiring in the wording that a redeclaration of a function that contains
a contract needs to use the same contract (in the sense of ODR)
that was present in the first declaration of the function.
</p>

<p>
The exact meaning would be to require contracts to be lexically the same token by token.
This is a simpler definition, but would require that a redeclaration uses also the same
names for functions arguments (if/when they are used in the contract).
</p>

<p>
A second solution would be to require the contracts to be logically equivalent which seems
to introduce a number of additional implementation challenges.
</p>

<p>
A third option is to say that the functions must be textually equivalent except
for a change of (parameter) variable names, but otherwise having the same
structure. We have selected this option.
</p>

<p>
We have taken the route of requiring contract expressions to be odr-identical,
except for the change of function parameter names.
</p>

<h3>2.8 Throwing violation handler</h3>

<p>
If a violation handler throws an exception, it is necessary to clarify what is the effect
when the continuation mode is <i>off</i>.
</p>

<p>
One option could be that the exception propagates as the handler did not
<i>return</i>. However, that design option would open the opportunity for continuation
when the continuation has been set to <i>off</i>.
</p>

<p>
Another design alternative would be to unconditionally invoke <tt><b>terminate()</b></tt>.
</p>

<h3>2.9 Additional information in contract violation</h3>

Besides original information in <tt><b>contract_violation</b></tt>, a new member
has been added to store the <tt><b>assertion_level</b></tt>. This value contains
a string with the <i>assertion-level</i> of the contract that has been violated.

<h3>2.10 Invoking the handler</h3>

The proposal does not support the direct invocation of the violation handler.
Allowing so, would imply access to handler supplied by the user, and could
result into a security issue.

Instead, we have added an additional <i>assertion-level</i> named
<tt><b>always</b></tt>. Such assertion cannot be disbled and the check is
performed even when the program is built with <i>build-level</i> set to
<i>off</i>.

<pre><b>
void f() {
 int x=get_value();
 [[assert always: x>0]]; // Invoke handler if x non-positive
 // ...
 if (x!=0) [[assert always: false]]; // Invoke handler if x!=0
 // ...
 [[assert always:true]]; // Unconditionally invoke handler
 // ...
}
</b></pre>
<p/>

This assertion level is available only for <tt><b>[[assert]]</b></tt>. A future
extension migh consider the usefulness of <tt><b>always</b></tt> for
preconditions and postconditions.

<h5>Background of always level</h5>

The addition of the <i>always</i> assertion level was introduced during the Kona
meeting. We reproduce here the relevant results from straw polls in the Evolution Working
Group.
<p/>

<table border="1" cellpadding="5">
<thead>
  <tr>
    <td>Question</td>
    <td>SF</td>
    <td>F</td>
    <td>N</td>
    <td>A</td>
    <td>SA</td>
  </tr>
</thead>
<tbody>
  <tr>
    <td>Accept and proceed to LEWG</td>
    <td>13</td> <td>6</td> <td>5</td> <td>4</td> <td>4</td>
  </tr>
  <tr>
    <td>Accept and proceed to LEWG without <i>always</i></td>
    <td>5</td> <td>13</td> <td>9</td> <td>5</td> <td>2</td>
  </tr>
</tbody>
</table>
<p/>

Also, an up-down vote was taken:
<p/>
<table border="1" cellpadding="5">
<thead>
  <tr>
    <td>Proposal as is</td>
    <td>Proposal wihtout <i>always</i></td>
  </tr>
</thead>
<tbody>
  <tr>
    <td>14</td>
    <td>9</td>
  </tr>
</tbody>
</table>

<h5>Note</h5>

This version of the document does not include wording for the <i>always</i> level.

<h3>2.11 Issues to be solved</h3>

<h4>Initialization of contract_violation objects</h4>

<p>
When a contract is broken, a <tt><b>contract_violation</b></tt> needs to be created with
the corresponding information. There are several options on how such object should
be populated with information.
</p>

<p>
Among the available options, one could be to leave this details as something to be defined
by implementations. Otherwise, the exact population approach would need to be standardized.
</p>

<h4>Additional information in violation_info objects</h4>

<p>
Besides the information already defined in <tt><b>contract_violation</b></tt>, additional information
might be useful. One example of such information is the assertion level of the 
contract assertion whose check generated the invocation of the violation handler.
</p>

<h2>3. Questions about contracts programming</h2>

<h3>What is the effect of violating a contract while evaluating the check for
another expression</h3>

Nothing special needs to be considered. When the first contract is violated the
corresponding action is taken.

<pre><b>
bool positive(int * p) [[expects: p!=nullptr]] {
  return *p > 0;
}

bool g(int * p) [[expects: positive(p)]];

void test() {
  g(nullptr); // Contract violation when calling positive(nullptr)
}
</b></pre>
</p>

<h3>Contract attribute as identifier</h3>

What happens if you try to use an identifier named as a contract attribute (e.g.
<tt><b>requires</b></tt>, <tt><b>audit</b></tt>, ...)?

Example:

<pre><b>
X f(X & audit) [[ensures audit: audit.valid()]];
</b></pre>
</p>

This is valid code. The first <tt><b>audit</b></tt> is interpreted as a
<i>contract-level</i>. Then, the <i>conditional-expression</i> identifies the
second <tt><b>audit</b></tt> correctly as the function argument.




<h2>4. Proposed Wording</h2>

<p>Modify [5.1.5/6] as follows:

<blockquote class="std">
<p>
6 The closure type for a non-generic <i>lambda-expression</i> has a public inline function call operator (13.5.4)
whose parameters and return type are described by the <i>lambda-expression</i>'s <i>parameter-declaration-clause</i>
and <i>trailing-return-type</i> respectively. For a generic lambda, the closure type has a public inline function call
operator member template (14.5.2) whose <i>template-parameter-list</i> consists of one invented type <i>template-parameter</i>
for each occurrence of <tt><b>auto</b></tt> in the lambda’s <i>parameter-declaration-clause</i>, in order of appearance.
The invented type <i>template-parameter</i> is a parameter pack if the corresponding <i>parameter-declaration</i> declares
a function parameter pack (8.3.5). The return type and function parameters of the function call operator
template are derived from the <i>lambda-expression</i>’s <i>trailing-return-type</i> and <i>parameter-declaration-clause</i> by
replacing each occurrence of <tt><b>auto</b></tt> in the <i>decl-specifiers</i> of the <i>parameter-declaration-clause</i> with the name of
the corresponding invented template-parameter.
[<i>Example:</i>
<pre><b>
auto glambda = [](auto a, auto&amp;&amp; b) { return a &lt; b; };
bool b = glambda(3, 3.14); 				// OK
auto vglambda = [](auto printer) {
  return [=](auto&amp;&amp; ... ts) {				// OK: ts is a function parameter pack
    printer(std::forward&lt;decltype(ts)&gt;(ts)...);

    return [=]() {
      printer(ts ...);
    };
  };
};
auto p = vglambda( [](auto v1, auto v2, auto v3)
{ std::cout &lt;&lt; v1 &lt;&lt; v2 &lt;&lt; v3; } );
auto q = p(1, ’a’, 3.14); 				// OK: outputs 1a3.14
q(); 							// OK: outputs 1a3.14
</b></pre>
&mdash; <i>end example</i> ] 
This function call operator or operator template is declared <tt><b>const</b></tt> (9.2.2) if and only if
the <i>lambda-expression</i>’s <i>parameter-declaration-clause</i> is not followed by <tt><b>mutable</b></tt>. 
It is neither virtual nor
declared <tt><b>volatile</b></tt>. Any <i>noexcept-specifier</i> specified on a <i>lambda-expression</i> applies to the corresponding
function call operator or operator template. An <i>attribute-specifier-seq</i> in a <i>lambda-declarator</i> appertains
to the <del>type of the</del> corresponding function call operator or operator template. The function call operator
or any given operator template specialization is a <tt><b>constexpr</b></tt> function if either the corresponding <i>lambda-expression</i>’s
<i>parameter-declaration-clause</i> is followed by <tt><b>constexpr</b></tt>, or it satisfies the requirements for a
<tt><b>constexpr</b></tt> function (7.1.5). 
[ <i>Note:</i>
Names referenced in the <i>lambda-declarator</i> are looked up in the context in
which the <i>lambda-expression</i> appears. 
&mdash; <i>end note</i> ] 
[ Example:
<pre><b>
auto ID = [](auto a) { return a; };
static_assert(ID(3) == 3); // OK

struct NonLiteral {
  NonLiteral(int n) : n(n) { }
  int n;
};
static_assert(ID(NonLiteral{3}).n == 3); // ill-formed
</b></pre>
&mdash; <i>end example</i> ] 
</p>
</blockquote>

<p>Modify [7/2] as follows:
<blockquote class="std">
2.
A simple-declaration or nodeclspec-function-declaration of the form
  <blockquote class="grammar">
    <i>attribute-specifier-seq<sub>opt</sub> decl-specifier-seq<sub>opt</sub> init-declarator-list<sub>opt</sub> <tt>;</tt></i>
  </blockquote>
is divided into three parts. Attributes are described in 7.6. <i>decl-specifiers</i>, the principal components of a
<i>decl-specifier-seq</i>, are described in 7.1. declarators, the components of an <i>init-declarator-list</i>, are described
in Clause 8. The <i>attribute-specifier-seq</i> appertains to each of the entities declared by the declarators of the
init-declarator-list. 
[ <i>Note:</i> 
In the declaration for an entity, attributes appertaining to that entity may appear
at the start of the declaration <del>and</del><ins>,</ins> after the <i>declarator-id</i> for that declaration
<ins>, or at the end of the function declaration</ins>. 
&mdash; <i>end note</i> ] 
[ <i>Example</i>:
<pre><b>
[[noreturn]] void f [[noreturn]] ()<ins>[[noreturn]]</ins>; // OK
</b></pre>
&mdash; <i>end example</i> ]
</blockquote>

<p>In [7.6.1/1], modify the production for <i>attribute</i> as follows:</p>
<blockquote class="std">
  <blockquote class="grammar">
    &hellip;<br/>
    <i>attribute-specifier:</i><br/>
    <tab><tt><b>[[</b></tt><i>attribute-using-prefix<sub>opt</sub>&nbsp;&nbsp;attribute-list</i><tt><b>]]</b></tt><br/>
    <tab><ins><tt><b>[[</b></tt><i>contract-attribute contract-level<sub>opt</sub>&nbsp;&nbsp;identifier<sub>opt</sub>&nbsp;<tt>:</tt>&nbsp;conditional-expression</i><tt><b>]]</b></tt></ins><br/>
    <tab><i>alignment-specifier</i><br/>
    &hellip;<br/>
  </blockquote>
</blockquote>

<p>In [7.6.1/1], add a new production for <i>contract-attribute</i> as follows:</p>
<blockquote class="std">
  <blockquote class="grammar">
    &hellip;<br/>
    <ins>
    <i>contract-attribute:</i><br/>
    <tab><tt>expects</tt><br/>
    <tab><tt>ensures</tt><br/>
    <tab><tt>assert</tt><br/>
    </ins>
    &hellip;<br/>
  </blockquote>
</blockquote>

<p>In [7.6.1/1], add a new production for <i>contract-level</i> as follows:</p>
<blockquote class="std">
  <blockquote class="grammar">
    &hellip;<br/>
    <ins>
    <i>contract-level:</i><br/>
    <tab><tt>default</tt><br/>
    <tab><tt>audit</tt><br/>
    <tab><tt>axiom</tt><br/>
    </ins>
    &hellip;<br/>
  </blockquote>
</blockquote>


<p>Add a new section 7.6.11 Contracts attributes <tt><b>[dcl.attr.contracts]</b></tt></p>

<blockquote class="stdins">

<p>
1.
A <i>precondition</i> is a predicate that should hold upon entry into a function.
It expresses a function's expectation on its arguments and/or the state of objects that may be used by the function.
Preconditions are expressed by <tt>expects</tt> attributes (7.6.10).
</p>

<p>
2.
A <i>postcondition</i> is a predicate that should hold upon exit from a function.
It expresses the conditions that a function should ensure for the return value and/or the state
of objects that may be used by the function.
Postconditions are expressed by <tt>ensures</tt> attributes (7.6.11).
</p>

<p>
3.
An <i>assertion</i> is a predicate that should hold at its point in a function body.
It expresses the conditions, on objects that accessible at its point in a body, that must be satisfied.
Assertions are expressed by <tt>assert</tt> attributes (7.6.12).
</p>

<p>
4. 
Preconditions, postoconditions, and assertions are collectively called <i>contracts</i>.
A contract shall have no observable effect in a correct program (a program where
all contracts would be satisfied, if they were evaluated).
</p>

<p>
5.
Contract attributes are followed by a <i>conditional-expression</i>, which is a potentially evaluated expression (3.2).
[<i>Example</i><br/>
<pre><b>
void push(int x, queue &amp; q)
  [[expects: !q.full()]]
  [[ensures: !q.empty()]]
{
  //...
  [[assert: q.is_valid()]];
  //...
}
</b></pre>
&mdash; <i>end example</i>]
</p>

<p>
6.
A contract attribute may be combined with the following <i>contract-level</i>s:
<tt>default</tt>, <tt>audit</tt>, and <tt>axiom</tt> to express 
the <i>assertion-level</i> of the contract. When no modifier is provided, the 
<i>assertion-level</i> of the precondition is <tt>default</tt>.
[<i>Note:</i>
A <tt>default</tt> <i>assertion-level</i> is expected to be used for those preconditions, postconditions and assertions
 where the cost of run-time checking 
is assumed to be small (or at least not expensive) compared to the cost of executing the function.
An <tt>audit</tt> <i>assertion-level</i> is expected to be used for those preconditions, postconditions and assertions
where the cost of run-time checking
is assumed to be large (or at least significant) compared to the cost of executing the function.
An <tt>axiom</tt> <i>assertion-level</i> is expected to be used for those preconditions, postconditions and assertions
 that are formal comments and are not evaluated at run-time.
&mdash; <i>end note</i>]
</p>

<p>
7.
A program with a contract expression that performs an observable modification of an object is ill-formed;
no diagnostic required.
</p>

<p>
8.
A contract of a <tt>constexpr</tt> function cannot refer to non-local objects that are not
constexpr.
[<i>Example</i>
<pre><b>
int min=-42;
constexpr int max=42;

constexpr int f(int x)
  [[expects: min&lt;=x]] // error
  [[expects: x&lt;max]] // OK
{
  //...
}
</b></pre>
&mdash; <i>end example</i>]
</p>

<p>
9.
Every redeclaration of a function must contain exactly the same contract that was
present in the first declaration of that function or completely omit the contract.
The contracts expression shall be odr identical except for the change of
function parameter names.  </p>

<p>
10.
A translation may be performed with one of the following <i>build levels</i>:
<i>off</i>, <i>default</i>, or <i>audit</i>.
A translation with <i>build level</i> set to <i>off</i> shall not check any
contract.
A translation with <i>build level</i> set to <i>default</i> shall perform
checking for <i>default</i> contracts.
A translation with <i>build level</i> set to <i>audit</i> shall perform checking
for <i>default</i> and <i>audit</i> contracts.
[<i>Note:</i>
The mechanism for selecting the <i>build level</i> is implementation defined.
If no <i>build level</i> is selected, the <i>build level</i> is <i>default</i>.
&mdash; <i>end note</i>]
There shall be no programmatic way of setting, modifying or querying the <i>build level</i> of a translation unit.
</p>

<p>
11.
If a function has multiple preconditions or postconditions that would be checked,
their evaluation will be performed in the order they appear.
<pre><b>
void f(int * p)
  [[expects: p!=nullptr]]
  [[expects: *p == 0]] // Only checked when p!=nullptr
{
  *p = 1;
}
</b></pre>
</p>

<p>
12.
A <i>violation handler</i> function is a function with the following signature:
<pre><b>
void(const std::contract_violation &amp;);
</b></pre>
</p>

<p>
13.
If a contract violation is detected, a <i>violation handler</i> will be invoked.
It shall be implementation defined how the violation handler is established for a program and how the 
<tt><b>std::contract_violation</b></tt> argument value is set.
There shall not be any programmatic way of setting or modifying the which violation handler
is called in the event of a contract violation.
</p>


<p>
14.
If a user-provided violation handler exits by throwing an exception and a contract
is violated in a call to a function with a <i>non-throwing</i> exception specification,
then the behavior is as if the exception was thrown within the function body.
[<i>Note:</i>
The function <b><tt>std::terminate()</tt></b> will be invoked.
No stack unwinding will be performed.
&mdash; <i>end note</i>]
[<i>Example:</i>
<pre><b>
void f(int x) noexcept [[expects: x>0]];

void g() {
  f(0); // std::terminate() if violation handler throws
  //...
}
</b></pre>
&mdash; <i>end example</i>]
</p>

<p>
15.
A translation may be performed with a <i>violation continuation mode</i>, which can be: <i>off</i> or <i>on</i>.
A translation with a violation continuation mode set to </i>off</i> shall terminate execution by
invoking <b><tt>std::terminate()</tt></b> after completing the execution of the violation handler. 
A translation with a violation continuation mode set to <i>on</i>
shall continue execution after completing the execution of the violation handler.
[<i>Note:</i>
If no <i>continuation mode</i> is selected, the default <i>continuation mode</i> is <i>off</i>.
&mdash; <i>end note</i>]
[<i>Note:</i>
A <i>continuation mode</i> set to <i>on</i> provides the opportunity to install a logging handler to instrument
a pre-existing code base and fix errors before enforcing checks.
&mdash; <i>end note</i>]
[<i>Example:</i>
<pre><b>
void f(int x) [[expects: x > 0]];

void g() {
  f(0); // std::terminate() after handler if continuation mode is off
        // Proceeds after handler if continuation mode is on
  //...
}
</b></pre>
&mdash; <i>end example</i>]
</p>

</blockquote>

<p>Add a new section 7.6.11.1 Expects attribute <tt><b>[dcl.attr.contracts.expects]</b></tt></p>

<blockquote class="stdins">
<p>
1.
The <i>contract-attribute</i> <tt>expects</tt> may be applied only to a function declaration.
</p>

<p>
2.
The <i>contract-attribute</i> <tt>expects</tt> may appear multiple times applied to a function
declaration with the same or different <i>assertion level</i> modifiers.
[<i>Example</i>:
<pre><b>
void f(object &amp; o)
  [[expects: o.valid()]]
  [[expects audit: o.super_valid()]]
{
  //...
}
</b></pre>
&mdash; <i>end example</i>]
</p>

<p>
3.
The expression of a precondition from a function may use the function's arguments.
The expression of a precondition from a function template or a member function of a class template may use the template arguments.
The expression of a precondition from a public member function shall not use members from the protected or private interfaces.
The expression of a precondition from a protected member function shall not use members from the private interface.
The expression of a precondition from a <i>lambda-expression</i> may use any entity captured implictly or explictly.
The expression of a precondition from a <i>lambda-expression</i> shall not use any entity that is not accessible by <i>lambda-expression</i>.
</p>

<p>
4.
A function pointer shall not include preconditions.
A call through a function pointer to functions with preconditions shall
perform contract assertions checking once.
[<i>Example</i>:
<pre><b>
typedef int (*fpt)(int x) [[expects: x!=0]]; // Ill-formed

int g(int x) [[expects: x>=0]] 
{
  return x+1;
}

int (*pf)(int) = g; // OK
</b></pre>
&mdash; <i>end example</i>]
</p>

</blockquote>

<p>Add a new section 7.6.11.2 Ensures attribute <tt><b>[dcl.attr.contracts.ensures]</b></tt></p>

<blockquote class="stdins">
<p>
1.
The <i>contact-attribute</i> <tt>ensures</tt>  may be applied only to a function declaration.
</p>

<p>
2.
The <i>contract-attribute</i> <tt>ensures</tt> may appear multiple times applied to a function
declaration with the same or different <i>assertion level</i> modifiers.
[<i>Example</i>
<pre><b>
void f(object &amp; o)
  [[ensures: o.valid()]]
  [[ensures audit: o.super_valid()]]
{
  //...
}
</b></pre>
&mdash; <i>end example</i>]
</p>

<p>
3.
The expression of a postcondition from a function may use the function's arguments.
The expression of a postcondition from a function template or a member function of a class template may use the template arguments.
The expression of a postcondition from a public member function shall not use members from the protected or private interfaces.
The expression of a postcondition from a protected member function shall not use members from the private interface.
The expression of a postcondition from a <i>lambda-expression</i> may use any entity captured implictly or explictly.
The expression of a postcondition from a <i>lambda-expression</i> shall not use any entity that is not accessible by <i>lambda-expression</i>.
</p>

<p>
4.
A postcondition may introduce an identifier to represent the return value of the function.
[<i>Example:</i>
<pre><b>
int f(object &amp; o)
  [[ensures res: res&gt;0 &amp;&amp; o.valid()]];

int g(object &amp; o)
  [[ensures audit res: res!=0 &amp;&amp; o.super_valid()]]
{
  //...
}
</b></pre>
&mdash; <i>end example</i>]
</p>

<p>
5.
A function pointer shall not include postconditions.
A call through a function pointer to functions with postconditions shall
perform contract assertions checking once.
[<i>Example</i>:
<pre><b>
typedef int (*fpt)() [[ensures r: r!=0]]; // Ill-formed

int g(int x) 
  [[expects: x>=0]] 
  [[ensures r: r>x]]
{
  return x+1;
}

int (*pf)(int) = g; // OK
</b></pre>
&mdash; <i>end example</i>]
</p>

<p>
6.
If a postcondition odr-uses in its expression an argument value and the function body modifies that value
the program is ill-formed.
[<i>Example:</i>
<pre><b>
int f(int x)
  [[ensures r: r==x]] 
{
  return ++x; // Ill-formed: Modified
}

int g(int * p)
  [[ensures r: p!=nullptr]] 
{
  *p = 42; // OK. p is not modified
}
</b></pre>
&mdash; <i>end example</i>]

</p>

</blockquote>

<p>Add a new section 7.6.11.3 Assert attribute <tt><b>[dcl.attr.contracts.assert]</b></tt></p>

<blockquote class="stdins">
<p>
1.
The <i>contract-attribute</i> <tt>assert</tt> may be applied to a <i>statement</i>. 
</p>

<p>
2.
The expression of an assertion may use any object that can be accessed from the point of that assertion.
</p>
</blockquote>

<p>Modify clause [8.3.5/1]:</p>
<blockquote class="std"
<p>
1.
In a declaration <tt><b>T D</b></tt> where <tt><b>D</b></tt> has the form
<blockquote class="grammar">
<i><tt><b>D1</b></tt> <tt>(</tt> parameter-declaration-clause <tt>)</tt> cv-qualifier-seq<sub>opt</sub></i>
</blockquote>
<i>ref-qualifier<sub>opt</sub> noexcept-specifier<sub>opt</sub> attribute-specifier-seq<sub>opt</sub></i>
and the type of the contained <i>declarator-id</i> in the declaration <tt><b>T D1</b></tt> is 
“<i>derived-declarator-type-list</i> <tt><b>T</b></tt>”, the type
of the <i>declarator-id</i> in <tt><b>D</b></tt> is “<i>derived-declarator-type-list</i> <tt><b>noexcept</b></tt><sub><i>opt</i></sub>
 function of (<i>parameter-declaration-clause</i>) <i>cv-qualifier-seq<sub>opt</sub> ref-qualifieropt</i> returning <tt><b>T</b></tt>”, 
where the optional <tt><b>noexcept</b></tt> is present if and only if the
exception specification (15.4) is non-throwing. The optional attribute-specifier-seq appertains to the function
<del>type</del>.
</p>

<p>
2.
In a declaration T D where D has the form
<blockquote class="grammar">
<i><tt><b>D1</b></tt> ( parameter-declaration-clause ) cv-qualifier-seq<sub>opt</sub></i><br/>
<tab><i>ref-qualifier<sub>opt</sub> noexcept-specifier<sub>opt</sub> attribute-specifier-seq<sub>opt</sub> trailing-return-type</i>
</blockquote>
and the type of the contained <i>declarator-id</i> in the declaration <tt><b>T D1</b></tt> is 
“<i>derived-declarator-type-list</i> <tt><b>T</b></tt>”, <tt><b>T</b></tt> shall be
the <i>single type-specifier</i> <tt><b>auto</b></tt>. The type of the <i>declarator-id</i> in <tt><b>D</b></tt>
is “<i>derived-declarator-type-list</i> <tt><b>noexcept</b></tt><sub><i>opt</i></sub>
function of (<i>parameter-declaration-clause</i>) <i>cv-qualifier-seq<sub>opt</sub> ref-qualifier<sub>opt</sub></i> returning <tt><b>U</b></tt>”, 
where <tt><b>U</b></tt> is the type
specified by the <i>trailing-return-type</i>, and where the optional <tt><b>noexcept</b></tt> is present if and only if the exception
specification is non-throwing. The optional attribute-specifier-seq appertains to the function <del>type</del>.
</p>
</blockquote>

<p>Add at the end of clause 10.3:</p>

<blockquote class="stdins">
<p>
17.
An overriding function shall have exactly the same contract that was declared for that
function in the base class. However, the contract in the overriding function may be 
omitted in which case it has the same contract as was specified in the base class.
</p>
</blockquote>

Modify clause 17.5.1.3/2:
<blockquote class="std">
<p>
2.
A freestanding implementation has an implementation-defined set of headers. This set shall include at least
the headers shown in Table 19.
</p>
<table border="1" cellpadding="5" align="center">
<caption>Table 19 &mdash; C++ headers for freestanding implementations</caption>
<thead>
<tr>
<td>Subclause</td>
<td>Header(s)</td>
<tr>
</thead>
<tbody>
<tr>
<td/>
<td><tt>>&lt;ciso646</tt></td>
</tr>

<tr>
<td>
18.2 Types
</td><td>
<tt>&lt;cstddef&gt;</tt>
</td>
</tr>

<tr>
<td>
18.3 Implementation properties 
</td><td>
<tt>&lt;cfloat&gt;</tt> <tt>&lt;limits&gt;</tt> <tt>&lt;climits&gt;</tt>
</td>
</tr>

<tr>
<td>
18.4 Integer types 
</td><td>
<tt>&lt;cstdint&gt;</tt>
</td>
</tr>

<tr>
<td>
18.5 Start and termination 
</td><td>
<tt>&lt;cstdlib&gt;</tt>
</td>
</tr>

<tr>
<td>
18.6 Dynamic memory management 
</td><td>
<tt>&lt;new&gt;</tt>
</td>
</tr>

<tr>
<td>
18.7 Type identification 
</td><td>
<tt>&lt;typeinfo&gt;</tt>
</td>
</tr>

<tr>
<td>
<ins>18.8 Contract violation handling</ins>
</td><td>
<tt><ins>&lt;contract&gt;</ins></tt>
</td>
</tr>

<tr>
<td>
18.<del>8</del><ins>9</ins> Exception handling 
</td><td>
<tt>&lt;exception&gt;</tt>
</td>
</tr>

<tr>
<td>
18.<del>9</del><ins>10</ins> Initializer lists 
</td><td>
<tt>&lt;initializer_list&gt;</tt>
</td>
</tr>

<tr>
<td>
18.<del>10</del><ins>11</ins> Other runtime support 
</td><td>
<tt>&lt;cstdalign&gt;</tt> <tt>&lt;cstdarg&gt;</tt> <tt>&lt;cstdbool&gt;</tt>
</td>
</tr>

<tr>
<td>
20.15 Type traits 
</td><td>
<tt>&lt;type_traits&gt;</tt>
</td>
</tr>

<tr>
<td>
29 Atomics 
</td><td>
<tt>&lt;atomic&gt;</tt>
</td>
</tr>

</tbody>
</table>
</blockquote>

Modify clause 18.1/2:

<blockquote class="std">
<p>
2.
The following subclauses describe common type definitions used throughout the library, characteristics of
the predefined types, functions supporting start and termination of a C++ program, support for dynamic
memory management, support for dynamic type identification, <ins>support for contract violation handling,</ins>
support for exception processing, support for
initializer lists, and other runtime support, as summarized in Table 32.
</p>
<table border="1" cellpadding="5" align="center">
<caption>Table 32 &mdash; Language support library summary</caption>
<thead>
<tr>
<td>Subclause</td>
<td>Header(s)</td>
<tr>
</thead>
<tbody>

<tr>
<td>18.2 Common definitions</td>
<td>
<tt>&lt;cstddef&gt;</tt><br/>
<tt>&lt;cstdlib&gt;</tt>
</td>

<tr>
<td>18.3 Implementation properties</td>
<td>
<tt>&lt;limits&gt;</tt><br/>
<tt>&lt;climits&gt;</tt><br/>
<tt>&lt;cfloat&gt;</tt>
</td>
</tr>

<tr>
<td>18.4 Integer types</td>
<td><tt>&lt;cstdint&gt;</tt></td>
</tr>

<tr>
<td>18.5 Start and termination</td>
<td><tt>&lt;cstdlib&gt;</tt></td>
</tr>

<tr>
<td>18.6 Dynamic memory management</td>
<td><tt>&lt;new&gt;</tt></td>
</tr>

<tr>
<td>18.7 Type identification</td>
<td><tt>&lt;typeinfo&gt;</tt></td>
</tr>

<tr>
<td><ins>18.8 Contract violation handling</ins></td>
<td><ins><tt>&lt;contract&gt;</tt></ins></td>
</tr>

<tr>
<td>18.<del>8</del><ins>9</ins> Exception handling</td>
<td><tt>&lt;exception&gt;</tt></td>
</tr>

<tr>
<td>18.<del>9</del><ins>10</ins> Initializer lists</td>
<td><tt>&lt;initializer_list&gt;</tt></td>
</tr>

<tr>
<td>18.<del>10</del><ins>11</ins> Other runtime support</td>
<td>
<tt>&lt;csignal&gt;</tt><br/>
<tt>&lt;csetjmp&gt;</tt><br/>
<tt>&lt;cstdalign&gt;</tt><br/>
<tt>&lt;cstdarg&gt;</tt><br/>
<tt>&lt;cstdbool&gt;</tt><br/>
<tt>&lt;cstdlib&gt;</tt><br/>
</td>
</tr>

</tbody>
</table>
</blockquote>

Add a new section after 18.8
<blockquote class="stdins">
<h2>18.8 Contract violation handling</h2>

<p>
1.
The header <tt>&lt;contract&gt;</tt> defines a type for reporting information
about contract violations generated by the implementation.
</p>

<h3>18.8.1 Header &lt;contract&gt; synopsys</h3>
<pre>
namespace std {
  class contract_violation;
}
</pre>

<h3>18.8.2 Class <tt>contract_violation</tt></h3>
<pre><b>
namespace std {
  class contract_violation {
  public:
    int line_number() const noexcept;
    const char * file_name() const noexcept;
    const char * function_name() const noexcept;
    const char * comment() const noexcept;
    const char * contract_violation() const noexcept;
  };
}
</b></pre>

<p>
1.
The class <tt>contract_violation</tt> describes information about a contract violation generated by the implementation.
</p>

<pre><b>
int line_number() const noexcept;
</b></pre>
<p>
2.<tab>
<i>Returns:</i>
The line number where the contract violation happened.
</p>
<p>
3.<tab>
<i>Remarks:</i>
An implementation may return <tt>-1</tt> if the location is unknown.
</p>

<pre><b>
const char * file_name() const noexcept;
</b></pre>
<p>
4.<tab>
<i>Returns:</i>
The source file name where the contract violation happened.
</p>
<p>
5.<tab>
<i>Remarks:</i>
An implementation may return <tt>nullptr</tt> if the location is unknown.
</p>

<pre><b>
const char * function_name() const noexcept;
</b></pre>
<p>
6.<tab>
<i>Returns:</i>
The name of the function where the contract violation happened.
</p>
<p>
7.<tab>
<i>Remarks:</i>
An implementation may return <tt>nullptr</tt> if the function is unknown.
</p>

<pre><b>
const char * comment() const noexcept;
</b></pre>
<p>
8.<tab>
<i>Returns:</i>
The text of the contract that was violated.
</p>

<pre><b>
const char * assertion_level() const noexcept;
</b></pre>
<p>
9.<tab>
<i>Returns:</i>
The text with the <i>assertion-level</i> of the contract that was violated.
</p>

</blockquote>



<h3>Acknowledgements</h3>

Alexander Beels reviewed a previous version of this document.

Andrzej Krzemienski and Melissa Mears provided comments to a draft of this version.

<h3>References</h3>

<a name="bib-contracts-design">[1]</a>
G. Dos Reis, J. D. Garcia, J. Lakos, A. Meredith, N. Myers, B. Stroustrup.
A contract design. 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf">P0380R1</a>. 
July, 2016.<br/>

<a name="bib-cpp-draft">
[2]
</a> 
Richard Smith.
Working Draft, Standard for Programming Language C++.
<a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/n4618.pdf">N4618</a>
November, 2016.</br>

</body>
</html>



