<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <title>Contracts: why the house is not on fire (i.e. why the status quo is tolerable)</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: P1625R0
<br/>
Audience: WG21
<br/>
<br/>
<a href="mailto:ville.voutilainen@gmail.com">Ville Voutilainen</a><br/>
2019-03-11<br/>
</address>
<hr/>
<h1 align=center>Contracts: why the house is not on fire (i.e. why the status quo is tolerable)</h1>

<h2>Abstract</h2>

<p>
  This paper provides an explanation why there's no particular
  panic to make design changes to Contracts, and how fears
  of unlimited UB are.. ..mistaken.
</p>

<h2>Assumption of unchecked contracts</h2>

<p>
  Violations of unchecked contracts are Undefined Behavior. This causes
  severe heartburn to many audiences. However,
  <ol>
    <li>according to multiple implementation vendors, they are not likely
      (in fact, far from it) to
      assume contracts when continuation==on,</li>
    <li>it's perfectly plausible that implementations will provide switches
      to decide when or if contracts are assumed,</li>
    <li>..and they do not need to assume anything in their default build
      mode, in any of their existing optimized mode, or anything that
      would necessarily break existing programs even if contracts
      are introduced.</li>
  </ol>
</p>
<p>
  In other words: if you want your program to be unaffected by
  contracts, build with contract checking disabled and turn continuation
  on. Or just disable contract assumptions via implementation-specific
  means (which may translate to doing nothing special).
</p>

<h2>Why did you bother co-authoring a proposal to change it, then?</h2>

<p>
  Because I think it would be a better design to opt in to assumptions,
  rather than having them be a coupled part of the most-often used syntax.
  I also think we could ship C++20 without contract-based optimizations,
  and figure out how to add those later, perhaps in C++23.
</p>
<p>
  I would also really prefer having a portable way to write contracts
  that are not ever assumed, and be able to have the source code I write
  mean that. With the status quo, I need to invent novel schemes
  for that, and some of said schemes might end up involving macros.
</p>

<h2>Future evolution paths</h2>

<p>
  We haven't closed any evolution paths. They might need less convenient
  syntax than what is in the status quo, but that's perhaps more an
  inconvenience than a show-stopper problem.
</p>

</html>
