[basic.contract.eval]

# 6 Basics [[basic]](./#basic)

## 6.11 Contract assertions [[basic.contract]](basic.contract#eval)

### 6.11.2 Evaluation [basic.contract.eval]

[1](#1)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7606)

An evaluation of a contract assertion
uses one of the following four [*evaluation semantics*](#def:evaluation_semantics "6.11.2 Evaluation [basic.contract.eval]"):[*ignore*](#def:contract_evaluation_semantics,ignore "6.11.2 Evaluation [basic.contract.eval]"),[*observe*](#def:contract_evaluation_semantics,observe "6.11.2 Evaluation [basic.contract.eval]"),[*enforce*](#def:contract_evaluation_semantics,enforce "6.11.2 Evaluation [basic.contract.eval]"), or[*quick-enforce*](#def:contract_evaluation_semantics,quick-enforce "6.11.2 Evaluation [basic.contract.eval]")[.](#1.sentence-1)

Observe, enforce, and quick-enforce are [*checking semantics*](#def:contract_evaluation_semantics,checking "6.11.2 Evaluation [basic.contract.eval]");
enforce and quick-enforce are [*terminating semantics*](#def:contract_evaluation_semantics,terminating "6.11.2 Evaluation [basic.contract.eval]")[.](#1.sentence-2)

[2](#2)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7619)

It isimplementation-defined
which evaluation semantic is used
for any given evaluation of a contract assertion[.](#2.sentence-1)

[*Note [1](#note-1)*:

The range and flexibility of available choices of
evaluation semantics depends on the implementation
and need not allow all four evaluation semantics as possibilities[.](#2.sentence-2)

The evaluation semantics can differ
for different evaluations of the same contract assertion,
including evaluations during constant evaluation[.](#2.sentence-3)

— *end note*]

[3](#3)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7633)

*Recommended practice*: An implementation should provide
the option to translate a program
such that all evaluations of contract assertions use the ignore semantic
as well as
the option to translate a program
such that all evaluations of contract assertions use the enforce semantic[.](#3.sentence-1)

By default,
evaluations of contract assertions should use the enforce semantic[.](#3.sentence-2)

[4](#4)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7644)

The evaluation of a contract assertion using the ignore semantic has no effect[.](#4.sentence-1)

[*Note [2](#note-2)*:

The predicate is potentially evaluated ([[basic.def.odr]](basic.def.odr "6.3 One-definition rule")),
but not evaluated[.](#4.sentence-2)

— *end note*]

[5](#5)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7651)

The evaluation A of a contract assertion
using a checking semantic
determines the value of the predicate[.](#5.sentence-1)

It is unspecified
whether the predicate is evaluated[.](#5.sentence-2)

Let B be the value that would result from evaluating the predicate[.](#5.sentence-3)

[*Note [3](#note-3)*:

To determine whether a predicate would evaluate
to true or false,
an alternative evaluation
that produces the same value as the predicate
but has no side effects
can occur[.](#5.sentence-4)

[*Example [1](#example-1)*: struct S {mutable int g = 5;} s;void f() pre(( s.g++, false )); // #1void g(){ f(); // Increment of s.g might not occur, even if #1 uses a checking semantic.} — *end example*]

— *end note*]

[6](#6)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7680)

There is an observable checkpoint ([[intro.abstract]](intro.abstract "4.1.2 Abstract machine")) C that happens before A such that any other operation O that happens before A also happens before C[.](#6.sentence-1)

[7](#7)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7687)

A [*contract violation*](#def:contract_violation "6.11.2 Evaluation [basic.contract.eval]") occurs when

- [(7.1)](#7.1)

B is false,

- [(7.2)](#7.2)

the evaluation of the predicate
exits via an exception, or

- [(7.3)](#7.3)

the evaluation of the predicate
is performed in a context that is
manifestly constant-evaluated ([[expr.const]](expr.const "7.7 Constant expressions"))
and the predicate
is not a core constant expression[.](#7.sentence-1)

[*Note [4](#note-4)*:

If B is true,
no contract violation occurs and
control flow continues normally
after the point of evaluation of the contract assertion[.](#7.sentence-2)

The evaluation of the predicate
can fail to produce a value
without causing a contract violation,
for example,
by calling longjmp ([[csetjmp.syn]](csetjmp.syn "17.14.3 Header <csetjmp> synopsis"))
or terminating the program[.](#7.sentence-3)

— *end note*]

[8](#8)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7716)

If a contract violation occurs
in a context that is manifestly constant-evaluated ([[expr.const]](expr.const "7.7 Constant expressions")),
and the evaluation semantic is
a terminating semantic,
the program is ill-formed[.](#8.sentence-1)

[*Note [5](#note-5)*:

A diagnostic is produced
if the evaluation semantic is observe ([[intro.compliance]](intro.compliance "4.1 Implementation compliance"))[.](#8.sentence-2)

— *end note*]

[*Note [6](#note-6)*:

Different evaluation semantics
chosen for the same contract assertion
in different translation units
can result in
violations of the one-definition rule ([[basic.def.odr]](basic.def.odr "6.3 One-definition rule"))
when a contract assertion has side effects
that alter the value produced by a constant expression[.](#8.sentence-3)

[*Example [2](#example-2)*: constexpr int f(int i){contract_assert((++const_cast<int&>(i), true)); return i;}inline void g(){int a[f(1)]; // size dependent on the evaluation semantic of contract_assert above} — *end example*]

— *end note*]

[9](#9)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7752)

When the program is [*contract-terminated*](#def:contract-terminated "6.11.2 Evaluation [basic.contract.eval]"),
it isimplementation-defined
(depending on context) whether

- [(9.1)](#9.1)

std​::​terminate is called,

- [(9.2)](#9.2)

std​::​abort is called, or

- [(9.3)](#9.3)

execution is terminated[.](#9.sentence-1)
  [*Note [7](#note-7)*:
  No further execution steps occur ([[intro.progress]](intro.progress "6.10.2.3 Forward progress"))[.](#9.3.sentence-2)
 — *end note*]

[*Note [8](#note-8)*:

Performing the actions ofstd​::​terminate or std​::​abort without actually making a library call
is a conforming implementation of
contract-termination ([[intro.abstract]](intro.abstract "4.1.2 Abstract machine"))[.](#9.sentence-2)

— *end note*]

[10](#10)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7778)

If a contract violation occurs
in a context that is not manifestly constant-evaluated
and the evaluation semantic is quick-enforce,
the program is contract-terminated[.](#10.sentence-1)

[11](#11)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7786)

If a contract violation occurs
in a context that is not manifestly constant-evaluated
and the evaluation semantic is enforce or observe,
the contract-violation handler ([[basic.contract.handler]](basic.contract.handler "6.11.3 Contract-violation handler"))
is invoked with an lvalue referring to
an object v of type const std​::​contracts​::​contract_violation ([[support.contract.violation]](support.contract.violation "17.10.3 Class contract_­violation"))
containing information about the contract violation[.](#11.sentence-1)

Storage for v is allocated in an unspecified manner
except as noted in [[basic.stc.dynamic.allocation]](basic.stc.dynamic.allocation "6.8.6.5.2 Allocation functions")[.](#11.sentence-2)

The lifetime of v persists for the duration
of the invocation of the contract-violation handler[.](#11.sentence-3)

[12](#12)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7806)

If the contract violation occurred
because the evaluation of the predicate
exited via an exception,
the contract-violation handler is invoked
from within an active implicit handler
for that exception ([[except.handle]](except.handle "14.4 Handling an exception"))[.](#12.sentence-1)

If the contract-violation handler
returns normally
and the evaluation semantic is observe,
that implicit handler
is no longer considered active[.](#12.sentence-2)

[*Note [9](#note-9)*:

The exception can be inspected or rethrown within the contract-violation handler[.](#12.sentence-3)

— *end note*]

[13](#13)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7823)

If the contract-violation handler
returns normally
and the evaluation semantic is enforce,
the program is contract-terminated;
if violation occurred
as the result of an uncaught exception
from the evaluation of the predicate,
the implicit handler
remains active when contract termination occurs[.](#13.sentence-1)

[14](#14)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7835)

[*Note [10](#note-10)*:

If the contract-violation handler
returns normally
and the evaluation semantic is observe,
control flow continues normally
after the point of evaluation of the contract assertion[.](#14.sentence-1)

— *end note*]

[15](#15)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7845)

There is an observable checkpoint ([[intro.abstract]](intro.abstract "4.1.2 Abstract machine")) C that happens after the contract-violation handler returns normally
such that any other operation O that happens after the contract-violation handler returns
also happens after C[.](#15.sentence-1)

[16](#16)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7852)

[*Note [11](#note-11)*:

The terminating semantics terminate the program
if execution would otherwise continue normally
past a contract violation:
the enforce semantic provides the opportunity to
log information about the contract violation
before terminating the program
or to throw an exception to avoid termination,
and the quick-enforce semantic is intended
to terminate the program as soon as possible
as well as
to minimize the impact of contract checks
on the generated code size[.](#16.sentence-1)

Conversely,
the observe semantic
provides the opportunity to
log information about the contract violation
without having to terminate the program[.](#16.sentence-2)

— *end note*]

[17](#17)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7873)

If a contract-violation handler
invoked from the evaluation of a function contract assertion ([[dcl.contract.func]](dcl.contract.func "9.4.1 General"))
exits via an exception,
the behavior is as if
the function body exits via that same exception[.](#17.sentence-1)

[*Note [12](#note-12)*:

A [*function-try-block*](except.pre#nt:function-try-block "14.1 Preamble [except.pre]") ([[except.pre]](except.pre "14.1 Preamble"))
is the function body when present
and thus does not
have an opportunity to catch the exception[.](#17.sentence-2)

If the function
has a non-throwing exception specification,
the function std​::​terminate is invoked ([[except.terminate]](except.terminate "14.6.2 The std​::​terminate function"))[.](#17.sentence-3)

— *end note*]

[*Note [13](#note-13)*:

If a contract-violation handler
invoked from an [*assertion-statement*](stmt.contract.assert#nt:assertion-statement "8.9 Assertion statement [stmt.contract.assert]") ([[stmt.contract.assert]](stmt.contract.assert "8.9 Assertion statement"))
exits via an exception,
the search for a handler
continues from the execution of that statement[.](#17.sentence-4)

— *end note*]

[18](#18)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7897)

To [*evaluate in sequence*](#def:evaluate_in_sequence "6.11.2 Evaluation [basic.contract.eval]") a list R of contract assertions:

- [(18.1)](#18.1)

  Construct a list of contract assertions S such that
  * [(18.1.1)](#18.1.1)

all elements of R are in S,

  * [(18.1.2)](#18.1.2)

each element of R may be repeated animplementation-defined
number of times
within S, and

  * [(18.1.3)](#18.1.3)

if a contract assertion A precedes another contract assertion B in R,
then the
first occurrence of A precedes the first occurrence of B in S[.](#18.1.sentence-1)

- [(18.2)](#18.2)

  Evaluate each element of S such that,
if a contract assertion A precedes a contract assertion B in S,
then the evaluation of A is sequenced before
the evaluation of B[.](#18.2.sentence-1)

[*Example [3](#example-3)*: void f(int i){contract_assert(i > 0); // #1contract_assert(i < 10); // #2// valid sequence of evaluations: #1 #2// valid sequence of evaluations: #1 #1 #2 #2// valid sequence of evaluations: #1 #2 #1 #2// valid sequence of evaluations: #1 #2 #2 #1// invalid sequence of evaluations: #2 #1} — *end example*]

[19](#19)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/basic.tex#L7945)

*Recommended practice*: An implementation should
provide an option to perform
a specified number of repeated evaluations
for contract assertions[.](#19.sentence-1)

By default,
no repeated evaluations should be performed[.](#19.sentence-2)