<!DOCTYPE HTML>
<html>
<head>
	<title>Ship Contracts in a TS</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 align=right>
Document number: P3265R0
<br/>
Audience: EWG
<br/>
<br/>
<a href="mailto:ville.voutilainen@gmail.com">Ville Voutilainen</a><br/>

2024-05-05<br/>
</address>
<hr/>
<h1 align=center>Ship Contracts in a TS</h1>

<h2>Abstract</h2>

<p>This paper suggests that Contracts should ship in a Technical Specification
  first, not in the C++26 IS.</p>

<p>The motivation for this is many-fold. We lack
  <ul>
    <li>implementation experience</li>
    <li>more importantly, field experience in the form of deployment and usage experience</li>
    <li>WG21-wide design consensus on multiple points in P2900</li>
    <li>cohesion and coverage; we don't have WG21-wide consensus on
      how to deal with virtual functions, how to deal with coroutines,
      and how to deal with pointers to functions</li>
    <li>increased safety; contract assertions are subject to as much
      undefined behavior as the rest of the language is, and this may well
      be very problematic both for the runtime checks written in contract
      assertions and also for the chances of static analysis tools' ability
      to correctness-check code with the help of contract assertions.</li>
  </ul>
</p>

<h2>Additional ruminations</h2>

<p>There isn't actually much to add.</p>

<p>For those unaware, we have had language TSes before, for Concepts,
  Modules, and Coroutines. Those were, regardless of the grumbling
  about the time and effort they took, all successful in the sense
  that we got better language features due to using a TS, with
  fewer if any unaddressed concerns, with a better understanding,
  and better consensus in WG21.</p>

<p>We have various design disagreements in SG21, and based on EWG's
  look at Contracts in Tokyo, fair amounts of disagreements between
  what SG21 is currently proposing and what some portions of EWG
  think about it. We can certainly try to resolve all such differences
  and ship the result in C++26, but that seems unwise. We should hopefully
  have more than paper-exercise disagreements that are resolved on paper -
  we should try to resolve those disagreements with something more concrete
  than papers in our hands, and that something more concrete should
  be implementations we can play with.</p>

<p>And that includes implementations of different alternatives instead of just
  one, to have an antithesis for the thesis, with the goal of producing
  a better synthesis.</p>

<p>Finally, there's been various discussions in SG21, including significant
  parts of the discussion on <a href="https://wg21.link/p2680">P2680</a>
  where statements along the lines of "if we want to ship this in C++26,
  we should do $foo and $bar, but not $baz" have been made.
  That is, the schedule goal
  for shipping the Contracts MVP has a significant impact on what we look
  at and when. While that's understandable for an MVP approach, it also
  runs into the danger of closing alternative design doors prematurely,
  when they don't fit into the MVP schedule and the timeline to make
  it into C++26 - even when they might be better doors to walk through.</p>

<p>So, the main goal of this idea, in addition to getting a better understanding,
  more field experience, and all that jazz, is to remove that urgency,
  and hopefully remove its significant impact on the design choices that
  we make. Decouple Contracts from such an immediate deadline, have a breather,
  gather more experience. Use the ISO trial balloon that is a Technical
  Specification to do it. 
</p>
</body>
</html>
