<!DOCTYPE HTML>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
	<title>Contracts and profiles: what can we reasonably ship in C++26</title>

	<style>
	p {text-align:justify}
	li {text-align:justify}
	blockquote.note
	{
		background-color:#E0E0E0;
		padding-left: 15px;
		padding-right: 15px;
		padding-top: 1px;
		padding-bottom: 1px;
	}
	ins {color:#00A000}
	del {color:#A00000}
	</style>
</head>
<body>

<address>
Document number: P3608R0
<br/>
Audience: EWG
<br/>
<br/>
<a href="mailto:ville.voutilainen@gmail.com">Ville Voutilainen</a><br/>
<a href="mailto:cxx@kayari.org">Jonathan Wakely</a><br/>
<a href="mailto:gdr@microsoft.com">Gabriel Dos Reis</a><br/>

2025-01-28<br/>
</address>
<hr/>
<h1>Contracts and profiles: what can we reasonably ship in C++26</h1>

<h2>Abstract</h2>

<p>
This paper proposes that we postpone novel ideas to either white papers
that we ship before C++29, or to C++29.
</p>
<p>Furthermore, this paper proposes that we ship exactly three things
  related to these problem domains in C++26:</p>
<ol>
  <li>the general profiles framework, <a href="https://open-std.org/JTC1/SC22/WG21/docs/papers/2025/p3589r0.pdf">P3589</a>.</li>
  <li>the standard library hardening, <a href="https://open-std.org/JTC1/SC22/WG21/docs/papers/2024/p3471r2.html">P3471</a>.</li>
  <li>a concrete profile that switches on the standard library hardening, and makes the violations of hardened preconditions just terminate the program, without any additional flexibility for C++26. Implementation vendors are, however, encouraged not to close the door for other violation handling strategies as extensions or as standardized strategies in the future.</li>
</ol>
<p>
Ship everything else when it's mature, including the additional flexibility of a violation of a hardened precondition invoking a user-defined hook, so as to prevent unconditional termination.
</p>
<p>If we think we absolutely have to ship some other profile, like the
  proposed Types profile, we can ship it as a profile that must be
  enabled as experimental (e.g. as suggested in <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3447r0.pdf">P3447</a>).</p>

<h2>Rationale</h2>

<p>
  Contracts have unaddressed design issues and disagreements (see
  <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3573r0.pdf">P3573</a>),
  especially in the realm of
  how contracts work on virtual functions. We have neither a good agreement
  on that nor actual deployment experience on reasonable-scale use of
  contracts on virtual functions.
</p>
<p>We have various outstanding issues with the current profiles proposal,
  especially the parts where it adds expression-level language checks
  for things like uses of operator[], and how that interacts with libraries
  that for various reasons do not need nor want such checks.
</p>
<p>We have a very unclear picture on how contracts and profiles should
  interact and interoperate.
</p>
<p>And all this with our noses pressed against a deadline. We are rushing
  things in, without employing prudent engineering practices, most importantly
  the quality assurance ones, quite plainly meaning especially testing.
</p>

<p>In contrast to that, the standard library hardening is existing practice, and
  comes with very positive field experience reports. Two out of three
  of our major library vendors already ship it, and the third one is
  working on it actively. The missing piece in the picture for the
  wider C++ programmer audience is how to enable that checking.
</p>

<h3>The debates on what we absolutely need right now</h3>

<p>Various members of our group will happily tell you that we are in dire
  need to ship various more-featured solutions immediately, in C++26, or else the
  whole user community faces unmitigable perils.</p>

<p>We should avoid the temptation of pushing unfinished facilities
  in because we feel an urgency.</p>

<p>I must also point out that if such impending doom is upon us, we need
  to deal with it effectively, with solutions and responses that actually
  work, aren't guesswork, and are field-tested. Otherwise there's a very
  good chance that hastily adopted solutions end up making the situation
  worse, because we will end up over-advertising the capabilities of solutions,
  and thereby shipping something much worse and less functional
  than smaller incremental steps.
</p>

<h2>Summary</h2>

<p>Ship the stable and mature existing practice. Don't ship wild guesses.
  Ship what's in our current pipeline for profiles and contracts once
  we've had the chance to work on them further, to resolve various
  issues, to improve consensus, and to make all those facilities work
  together as a coherent whole.</p>
</body>
</html>
