<html>
<head>
<title>P3835R0: Contracts make C++ less safe -- full stop</title>

<style type="text/css">
p.example { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }
  ins { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  .new { text-decoration:none; font-weight:bold; background-color:#D0FFD0 }
  del { text-decoration:line-through; background-color:#FFA0A0 }  
  strong { font-weight: inherit; color: #2020ff }
  table, td, th { border: 1px solid black; border-collapse:collapse; padding: 5px }
</style>
</head>

<body>
P3835R0<br/>
John Spicer &lt;jhs@edg.com><br/>
Ville Voutilainen &lt;ville.voutilainen@gmail.com><br/>
Jose Daniel Garcia Sanchez &lt;josedaniel.garcia@uc3m.es><br/>
Audience: EWG, CWG, LWG<br/>
2025-09-03<br/>

<h1>P3835R0: Contracts make C++ less safe -- full stop!</h1>

<h2>Introduction</h2>

<p>
Contracts, as specified in P2900R10, were added to the C++ working draft at
the February 2025 meeting.
<p>
P2900 says "When used correctly, contract assertions can significantly
improve the safety and correctness of software".
<p>
P2900 also says "In practice, the choice of semantic will most likely be controlled by a command-line option to the compiler".

<h2>The Problem (or at least one of the problems)</h2>
<p>
Users are likely to want to apply a given semantic to a given component of
a program. For example, a library provided by a third party might want to
make sure all of their code is always compiled with the quick_enforce semantic.
<p>
The contracts feature in the CD does not provide a mechanism to make sure that
a consistent semantic is provided for a given component.
<p>
This was pointed out in the February meeting of WG21 both my John Spicer
(and other authors), and also
by Eric Fiselier, who did (most or all) of the clang implementation of the
feature.
<p>
At that meeting, Eric said that the feature was essentially unusable without
some kind of label mechanism to allow semantics to be tied to components.
<p>
Eric suggested that a vendors agree on a set of attributes that could be used
until a solution in the standard is specified.
<p>
Such a vendor agreement has not been pursued and in the absence of such
an agreement, Eric has implemented a clang-specific set of attributes
and options to control this behavior:
<a href="https://contracts.efcs.ca/#contract-groups">
USING CLANG CONTRACTS
</a>

<h2>A trivial example</h2>

<p>
Consider this example where a library provides a header <code>z.h</code> and
an implementation (that is built into a binary library) of <code>l1.cpp</code>.
The library is build with the <code>quick_enforce</code> semantic to ensure
that any violations of the libraries plain-language contract are detected.
<p>
The client code as shown in <code>c1.cpp</code> is compiled with the
<code>ignore</code> semantic.
<p>
The programmer has no way of knowing which semantic will actually be applied
for any of the calls.
<p>
If the compiler choses not to inline the call in <code>l1.cpp</code> a version
of the function emitted as part of the compilation of <code>c1.cpp</code>
might be used, in which case the contract violation will not be detected.

<pre>
file: z.h

inline void f(int x) {
	contract_assert(x > 0);
}

file: l1.cpp

#include "z.h"

void g() {
	f(0); // expected to fail contract
}

file: c1.cpp

#include "z.h"

extern void g();

int main() {
	f(1); // expected to pass contract
	g();
}
</pre>

<p>
It has been suggested that a user with a sufficiently powerful linker and
the knowledge to use it appropriately might be able to work around this issue.
<p>
That is not a satisfactory answer for an important saftey issue. Even if a
user could manage that for simple cases like the one above, it would not
be a reasonable solution when more than two components are involved and/or
for a larger number of functions.

<h2>When does this problem occur?</h2>
The problem occurs in any case in which a header file contains an inline
function or a template definition (of any kind) that makes use of any
kind of contract assertion.

<h2>Do modules help?</h2>
<p>
This issues appears to be orthogonal to modules. If an attribute-like solution
were provided, it would presumably apply to uses of clients of the module.
In the absence of an attribute-like solution, an inline functtion or template
would presumably be treated simmilarly to such an entity appearing in a
header file
<h2>Conclusion</h2>
Contracts reduce the safety of C++ and should be removed until a version
that is strictly an improvement in safety is provided.
