<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="generator" content="pandoc">
  <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
  <title>P2032R0 &mdash; Contract Use Cases</title>
  <style type="text/css">code{white-space: pre;}</style>
  <style type="text/css">
a.sourceLine { display: inline-block; line-height: 1.25; }
a.sourceLine { pointer-events: none; color: inherit; text-decoration: inherit; }
a.sourceLine:empty { height: 1.2em; }
.sourceCode { overflow: visible; }
code.sourceCode { white-space: pre; position: relative; }
div.sourceCode { margin: 1em 0; }
pre.sourceCode { margin: 0; }
@media screen {
div.sourceCode { overflow: auto; }
}
@media print {
code.sourceCode { white-space: pre-wrap; }
a.sourceLine { text-indent: -1em; padding-left: 1em; }
}
pre.numberSource a.sourceLine
  { position: relative; left: -4em; }
pre.numberSource a.sourceLine::before
  { content: attr(title);
    position: relative; left: -1em; text-align: right; vertical-align: baseline;
    border: none; pointer-events: all; display: inline-block;
    -webkit-touch-callout: none; -webkit-user-select: none;
    -khtml-user-select: none; -moz-user-select: none;
    -ms-user-select: none; user-select: none;
    padding: 0 4px; width: 4em;
    color: #aaaaaa;
  }
pre.numberSource { margin-left: 3em; border-left: 1px solid #aaaaaa;  padding-left: 4px; }
div.sourceCode
  {  }
@media screen {
a.sourceLine::before { text-decoration: underline; }
}
code span.al { color: #ff0000; font-weight: bold; } /* Alert */
code span.an { color: #60a0b0; font-weight: bold; font-style: italic; } /* Annotation */
code span.at { color: #7d9029; } /* Attribute */
code span.bn { color: #40a070; } /* BaseN */
code span.bu { } /* BuiltIn */
code span.cf { color: #007020; font-weight: bold; } /* ControlFlow */
code span.ch { color: #4070a0; } /* Char */
code span.cn { color: #880000; } /* Constant */
code span.co { color: #60a0b0; font-style: italic; } /* Comment */
code span.cv { color: #60a0b0; font-weight: bold; font-style: italic; } /* CommentVar */
code span.do { color: #ba2121; font-style: italic; } /* Documentation */
code span.dt { color: #902000; } /* DataType */
code span.dv { color: #40a070; } /* DecVal */
code span.er { color: #ff0000; font-weight: bold; } /* Error */
code span.ex { } /* Extension */
code span.fl { color: #40a070; } /* Float */
code span.fu { color: #06287e; } /* Function */
code span.im { } /* Import */
code span.in { color: #60a0b0; font-weight: bold; font-style: italic; } /* Information */
code span.kw { color: #007020; font-weight: bold; } /* Keyword */
code span.op { color: #666666; } /* Operator */
code span.ot { color: #007020; } /* Other */
code span.pp { color: #bc7a00; } /* Preprocessor */
code span.sc { color: #4070a0; } /* SpecialChar */
code span.ss { color: #bb6688; } /* SpecialString */
code span.st { color: #4070a0; } /* String */
code span.va { color: #19177c; } /* Variable */
code span.vs { color: #4070a0; } /* VerbatimString */
code span.wa { color: #60a0b0; font-weight: bold; font-style: italic; } /* Warning */
  </style>
  <link rel="stylesheet" href="github.css">
  <!-- Style for Markdown -->
  <style>
  .md2html-container {
    max-width: 800px;
    margin: 0 auto;
  }
  .md2html-container > h1:first-child {
    margin-top: 0;
  }
  body {
  font-family: Helvetica, arial, sans-serif;
  font-size: 14px;
  line-height: 1.6;
  padding-top: 10px;
  padding-bottom: 10px;
  background-color: white;
  padding: 30px; }

body > *:first-child {
  margin-top: 0 !important; }
body > *:last-child {
  margin-bottom: 0 !important; }

a {
  color: #4183C4; }
a.absent {
  color: #cc0000; }
a.anchor {
  display: block;
  padding-left: 30px;
  margin-left: -30px;
  cursor: pointer;
  position: absolute;
  top: 0;
  left: 0;
  bottom: 0; }

h1, h2, h3, h4, h5, h6 {
  margin: 20px 0 10px;
  padding: 0;
  font-weight: bold;
  -webkit-font-smoothing: antialiased;
  cursor: text;
  position: relative; }

h1:hover a.anchor, h2:hover a.anchor, h3:hover a.anchor, h4:hover a.anchor, h5:hover a.anchor, h6:hover a.anchor {
  background: url("../../images/modules/styleguide/para.png") no-repeat 10px center;
  text-decoration: none; }

h1 tt, h1 code {
  font-size: inherit; }

h2 tt, h2 code {
  font-size: inherit; }

h3 tt, h3 code {
  font-size: inherit; }

h4 tt, h4 code {
  font-size: inherit; }

h5 tt, h5 code {
  font-size: inherit; }

h6 tt, h6 code {
  font-size: inherit; }

h1 {
  font-size: 28px;
  color: black; }

h2 {
  font-size: 24px;
  border-bottom: 1px solid #cccccc;
  color: black; }

h3 {
  font-size: 18px; }

h4 {
  font-size: 16px; }

h5 {
  font-size: 14px; }

h6 {
  color: #777777;
  font-size: 14px; }

p, blockquote, ul, ol, dl, li, table, pre {
  margin: 15px 0; }

hr {
  background: transparent url("../../images/modules/pulls/dirty-shade.png") repeat-x 0 0;
  border: 0 none;
  color: #cccccc;
  height: 4px;
  padding: 0; }

body > h2:first-child {
  margin-top: 0;
  padding-top: 0; }
body > h1:first-child {
  margin-top: 0;
  padding-top: 0; }
  body > h1:first-child + h2 {
    margin-top: 0;
    padding-top: 0; }
body > h3:first-child, body > h4:first-child, body > h5:first-child, body > h6:first-child {
  margin-top: 0;
  padding-top: 0; }

a:first-child h1, a:first-child h2, a:first-child h3, a:first-child h4, a:first-child h5, a:first-child h6 {
  margin-top: 0;
  padding-top: 0; }

h1 p, h2 p, h3 p, h4 p, h5 p, h6 p {
  margin-top: 0; }

li p.first {
  display: inline-block; }

ul, ol {
  padding-left: 30px; }

ul :first-child, ol :first-child {
  margin-top: 0; }

ul :last-child, ol :last-child {
  margin-bottom: 0; }

dl {
  padding: 0; }
  dl dt {
    font-size: 14px;
    font-weight: bold;
    font-style: italic;
    padding: 0;
    margin: 15px 0 5px; }
    dl dt:first-child {
      padding: 0; }
    dl dt > :first-child {
      margin-top: 0; }
    dl dt > :last-child {
      margin-bottom: 0; }
  dl dd {
    margin: 0 0 15px;
    padding: 0 15px; }
    dl dd > :first-child {
      margin-top: 0; }
    dl dd > :last-child {
      margin-bottom: 0; }

blockquote {
  border-left: 4px solid #dddddd;
  padding: 0 15px;
  color: #777777; }
  blockquote > :first-child {
    margin-top: 0; }
  blockquote > :last-child {
    margin-bottom: 0; }

table {
  border-collapse: collapse;
  padding: 0; }
  table tr {
    border-top: 1px solid #cccccc;
    background-color: white;
    margin: 0;
    padding: 0; }
    table tr:nth-child(2n) {
      background-color: #f8f8f8; }
    table tr th {
      font-weight: bold;
      border: 1px solid #cccccc;
      text-align: left;
      margin: 0;
      padding: 6px 13px; }
    table tr td {
      border: 1px solid #cccccc;
      text-align: left;
      margin: 0;
      padding: 6px 13px; }
    table tr th :first-child, table tr td :first-child {
      margin-top: 0; }
    table tr th :last-child, table tr td :last-child {
      margin-bottom: 0; }

img {
  max-width: 100%; }

span.frame {
  display: block;
  overflow: hidden; }
  span.frame > span {
    border: 1px solid #dddddd;
    display: block;
    float: left;
    overflow: hidden;
    margin: 13px 0 0;
    padding: 7px;
    width: auto; }
  span.frame span img {
    display: block;
    float: left; }
  span.frame span span {
    clear: both;
    color: #333333;
    display: block;
    padding: 5px 0 0; }
span.align-center {
  display: block;
  overflow: hidden;
  clear: both; }
  span.align-center > span {
    display: block;
    overflow: hidden;
    margin: 13px auto 0;
    text-align: center; }
  span.align-center span img {
    margin: 0 auto;
    text-align: center; }
span.align-right {
  display: block;
  overflow: hidden;
  clear: both; }
  span.align-right > span {
    display: block;
    overflow: hidden;
    margin: 13px 0 0;
    text-align: right; }
  span.align-right span img {
    margin: 0;
    text-align: right; }
span.float-left {
  display: block;
  margin-right: 13px;
  overflow: hidden;
  float: left; }
  span.float-left span {
    margin: 13px 0 0; }
span.float-right {
  display: block;
  margin-left: 13px;
  overflow: hidden;
  float: right; }
  span.float-right > span {
    display: block;
    overflow: hidden;
    margin: 13px auto 0;
    text-align: right; }

code, tt {
  margin: 0 2px;
  padding: 0 5px;
  white-space: nowrap;
  border: 1px solid #eaeaea;
  background-color: #f8f8f8;
  border-radius: 3px; }

pre code {
  margin: 0;
  padding: 0;
  white-space: pre;
  border: none;
  background: transparent; }

.highlight pre {
  background-color: #f8f8f8;
  border: 1px solid #cccccc;
  font-size: 13px;
  line-height: 19px;
  overflow: auto;
  padding: 6px 10px;
  border-radius: 3px; }

pre {
  background-color: #f8f8f8;
  border: 1px solid #cccccc;
  font-size: 13px;
  line-height: 19px;
  overflow: auto;
  padding: 6px 10px;
  border-radius: 3px; }
  pre code, pre tt {
    background-color: transparent;
    border: none; }
  </style>
  <!--[if lt IE 9]>
    <script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
  <![endif]-->
</head>
<body>


  
<p>Document no: P2032R0 <br/>
Date: 2020-03-02 <br/>
Authors:
Joshua Berne
<br/>
Reply-to: jberne4@bloomberg.net <br/>
Audience: SG21</p>
<h1>Contracts &mdash; What Came Before</h1>
<h2>Introduction</h2>
<p>Prior to the formation of SG21 there were a number of different potential
solutions proposed for contract based programming in the language.   With the
formation of SG21, a large number of use cases that any future contract
solution might need to satisfy have been presented and polled on (see
<a href="http://wg21.link/P1995R0">P1995</a>
for the use cases and the initial poll results).</p>
<p>In order to better understand these use cases, a number of people expressed
questions about how those use cases might be met with standard C++20 with no
language based contracts, and how each of the prior language proposals might
satisfy these use cases.  We hope this exposition helps in understanding the
use cases better, and helps to leverage the work that has gone before into
determining our future direction for language based contracts.</p>
<h2>Revision History</h2>
<p>Differences from first draft:</p>
<ul>
<li>The following scores have been adjusted: <a href="#dev.reason.confidence">dev.reason.confidence</a>, <a href="#dev.reason.importance">dev.reason.importance</a>, <a href="#dev.reason.cost">dev.reason.cost</a>, <a href="#dev.reason.sideeffects">dev.reason.sideeffects</a>, <a href="#dev.reason.behaviorcontrol">dev.reason.behaviorcontrol</a>, <a href="#dev.adapt">dev.adapt</a>, <a href="#cppdev.syntax.macros">cppdev.syntax.macros</a>, <a href="#cppdev.build.legacy">cppdev.build.legacy</a>, <a href="#int.control.runtime">int.control.runtime</a>, <a href="#teach.standardized">teach.standardized</a>, <a href="#teach.lifecycle">teach.lifecycle</a>, <a href="#teach.portable">teach.portable</a>, <a href="#teach.dumbstudents">teach.dumbstudents</a>, <a href="#teach.layering">teach.layering</a></li>
<li>The following notes have been adjusted: <a href="#cppapi.contracts.exception">cppapi.contracts.exception</a></li>
</ul>
<h2>Methodology</h2>
<p>There are 4 primary language variations that we wish to evaluate for their
merits at satisfying the SG21 use cases:</p>
<ul>
<li>N4842 - the current C++ working draft - is the closest appropximation
  currently available of what wil be the C++20 standard, and
  is (barring something incredibly surprising happening) going to ship with no
  explicit contract checking facilities in the language or standard library
  itself.  Many groups around the world have implemented contract checking
  libraries themselves (and come to the committee to attempt to build on those
  experiences to get those features into the language) and those libraries are
  still just as usable for contract checking in C++ today as they have always
  been.  We will reference the BDE libraries (https://github.com/Bloomberg/bde/,
  specifically bsls_assert and bsls_review, which can be found in
  https://github.com/bloomberg/bde/tree/master/groups/bsl/bsls)
  for examples of what can be done with no new language support.</li>
<li>N4820 - The C++ draft prior to the Summer 2019 WG21 meeting in Cologne - was
  the last draft that had the initially accepted contract checking facility.
  As with all of the other facilities we will discuss here, this proposal allowed
  for annotating contracts as boolean predicates within an attribute-like syntax
  that could be attached to functions as preconditions or postconditions, and
  put inside functions as assertions.   Three basic contract levels were
  allowed - <code>default</code>, <code>audit</code>, and <code>axiom</code> - with all levels either checked at
  runtime or introducing undefined behavior if not checked and violated.</li>
<li>P1429 - This paper primarily focuses on redefining the contract behavior of
  N4820 in terms of named semantics, and allowing for setting of the various
  contract levels (<code>default</code>, <code>audit</code>, and <code>axiom</code>) to specific behaviors (in lieu of
  the combination of build level and continuation mode available in N4820).</li>
<li>P1607 - This paper proposed removing the contract levels entirely and <em>only</em>
  allowing the setting of specific semantics, with the intent to provide more
  general build time control using macros until consensus could be reached on
  how that control should be presented.   This option, with no build levels
  and just four literal semantics, reached consensus in EWG on July 15th 2019,
  prior to the removal of contracts entirely from the draft.</li>
</ul>
<p>Rather than enumerate all possible variations that could be chosen, we will
focus on comparing P1429 with no literal semantics and P1607 with no contract
levels.</p>
<p>For each of these variations, we will assign a value in the range 0-100 for
each use case with roughly the following meanings:</p>
<ul>
<li>0 - Explicilty prohibitted or fundamnetally impossible.</li>
<li>25 - Feasible with great extra effort or in a highly limitted fashion, no
  useful support for this use case.</li>
<li>50 - Limitted support, with possible caveats that would prevent real
  satisfaction of this use case.</li>
<li>75 - Supported sufficiently to be used in a realistic situation.</li>
<li>100 - Fully supported with no major caveats.</li>
</ul>
<p>The goal of these numbers is to give a rough feeling for worth.  In the future,
we expect to see use cases given some weight (based partly on importance to the
community and partly on distinctness from other use cases), and then combined
with these numbers to give each solution a total value that can be used to
understand how effecitvely is satisfies the needs of the community.</p>
<p>Note that the long term goal here is not to give a number to say "you must vote
for this since it has a higher number" but rather to provide a value that
can be used to see "this solution measurably improves support for use cases that 
I personally might not consider important but that others do see as a
priority".</p>
<p>Additionally, a number of features could conceivably be built in a compatible way
on top of any of these proposals using a system built with preprocessor macros
(and such macros are the only viable way to build a system with no language
support).   Because of this, some scores are split into two numbers, the first
being a judgement on how well the proposal satisfies the use case "out of the box",
the second being how the proposal can be used with a macro facility above it to
meet the specified use case.</p>
<h2>Use Cases</h2>

<table>
  <tr>
    <th>#</th>
    <th>Code</th><th>As A</th><th>In Order To</th><th>I Want To</th>
  <th>N4842<br/>C++20</th>
  <th>N4820<br/>Pre-Cologne Draft</th>
  <th>P1429<br/>Semantic Level Control</th>
  <th>P1607<br/>Literal Semantics</th>
  </tr>


  

  <tr>
  <td>1</td>
  <td><a name="dev.reason.knowl">dev.reason.knowl</a></td>
  <td>Developer</td>
  <td>Reason explicitly</td>
  <td>Annotate my program anywhere in the code with my current understanding of its
structure or execution</td>


  <td>25
</td>

  <td>90
</td>

  <td>90
</td>

  <td>90
</td>
</tr>


<tr>
  <td colspan="9"> <p>Without a specific contract checking facility there are still ways to annotate
a program with information about program contracts, but those are limited to
either comments (with no validation or normative effect), the classic C <code>assert</code>
macro, or larger nonstandard macro-based facilities
(with no consistency in representation across different implementations).
Typical usage would be within a function writing something like this:</p>
<pre><code class="c++">void sqrt(double n) {
  assert(n &gt;= 0.0);
  BSLS_ASSERT(n &gt;= 0.0);
}
</code></pre>

<p>All of the contract proposals that were considered introduced the same syntax
for expressing an expectation that a certain boolean predicate was true at
specified points in a program.  These satisfy most common use cases in the wild
for contract predicates, although being only boolean predicates makes them
fall short of being able to capture many more involved or not runtime checkable
aspects of a function contract.  These include the ability to express this
within a function body as assertions like this:</p>
<pre><code class="c++">double  sqrt(double n) {
  [[ assert : n &gt;= 0.0 ]]
  // ..
}
</code></pre>

<p>More notably, annotations of expectations about execution could be added on
function declarations as well -- something not possible with a solely language based
solution -- like this:</p>
<pre><code class="c++">void sqrt(double n) [[ pre : n &gt;= 0.0 ]];
</code></pre> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>2</td>
  <td><a name="dev.reason.confidence">dev.reason.confidence</a></td>
  <td>Developer</td>
  <td>Reason explicitly</td>
  <td>Express a spectrum of confidence in my annotations, from "unsure" and asking
for validation, to "sure" and asking for some effect to be applied (eg.
"maybe", "definitely", "assume" 'something')</td>


  <td>40
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
  /40
</td>
</tr>

  <tr>
  <td>3</td>
  <td><a name="dev.reason.importance">dev.reason.importance</a></td>
  <td>Developer</td>
  <td>Reason explicitly</td>
  <td>Express a spectrum of importance of my annotations, from "critical" (eg. bring
the system down) to "minor" (eg. lead to a slower fallback)</td>


  <td>40
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
  /40
</td>
</tr>


<tr>
  <td colspan="9"> <p>While BDE's bsls_assert does not provide confidence as something that can be
used to control contract behavior, it is not hard to envision that such a thing
could be built into a macro-based solution.</p>
<p>Build-level-only solutions do not capture this at all (where N4820 and P1429
presented <code>default</code>, <code>audit</code>, and <code>axiom</code> as the only extra annotations that
could be put on a contract, and those were intended to capture cost of checking
not confidence).</p>
<p>P1607's literal semantics do not provide this directly, but here again one
could envision combining a macro-based solution to choose literal semantics
that would capture confidence or importance and compute behavior based on that.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>4</td>
  <td><a name="dev.reason.cost">dev.reason.cost</a></td>
  <td>Developer</td>
  <td>Reason explicitly</td>
  <td>Express a spectrum of expected cost at compile or runtime of my annotations,
from "unrunnable" to "expensive" to "cheap"</td>


  <td>40
</td>

  <td>80
</td>

  <td>80
</td>

  <td>0
  /50
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro-based solution would again be able to be built to use an expression
of the cost of checking to determine how a contract will be treated, and BDE
does exactly this with the following variations on how a contract can be
checked:</p>
<pre><code class="c++">void foo(int x) {
  BSLS_ASSERT_OPT(x != 0);
  BSLS_ASSERT(x &lt; Utils::getMaxXValue());
  BSLS_ASSERT_SAFE(factorial(x) &lt; Utils::getMaxXFactorial());
}
</code></pre>

<p>The <code>default</code>, <code>audit</code>, and <code>axiom</code> levels captured this similarly:</p>
<pre><code class="c++">void foo(int x) {
  [[ assert default : x != 0 ]];
  [[ assert audit : x &lt; Utils::getMaxValue() ]];
  [[ assert axiom : is_reachable( staticranges[x].begin(),
                                  staticranges[x].end() ) ]];
}
</code></pre>

<p>Similar to the case for confidence and importance, any system that was built
on top of literal semantics for P1607 with macros would be able to choose to
capture cost as part of that control of contract behavior.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>5</td>
  <td><a name="dev.reason.behavior">dev.reason.behavior</a></td>
  <td>Developer</td>
  <td>Reason about executions</td>
  <td>Have annotations affect the execution of my program in accordance with my
expectations</td>


  <td>25
</td>

  <td>75
</td>

  <td>90
</td>

  <td>90
</td>
</tr>


<tr>
  <td colspan="9"> <p>N4820 contracts allowed for contract checks to either introduce undefined
behavior or be checked at runtime.</p>
<p>P1429 and P1607 provide more flexibility by exposing the choice of 4 different
semantics for contracts, with the primary difference being the granularity of
that control.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>6</td>
  <td><a name="dev.reason.sideeffects">dev.reason.sideeffects</a></td>
  <td>Developer</td>
  <td>Reason about executions</td>
  <td>Ensure annotations do not substantially change the meaning of my program
whether enabled or disabled</td>


  <td>100
</td>

  <td>0
</td>

  <td>50
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>The primary meaning of this use case is that there should be a way to
use the contract facility (on or off) without undefined behavior.  This
does not preclude the ability to introduce undefined behavior - but it
needs to be optional.   N4820 fails to provide this.  A macro-based facility,
barring bugs, should be able to easily provide this.  P1429 and P1607
provide the ignore semantic with no violation-introduced undefiend behavior.</p>
<p>Both P1429 and P1607 did not fix the fact that any side effects in a predicate are
treated as undefined behavior.  Note that <a href="http://wg21.link/P1670R0">P1670R0</a>
was scheduled for Cologne which had one proposal for an attempt to address that.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>7</td>
  <td><a name="dev.reason.behaviorcontrol">dev.reason.behaviorcontrol</a></td>
  <td>Developer</td>
  <td>Reason about executions</td>
  <td>Have the effect of annotations on execution be user controllable (based on
whatever aspects, if any, are available).</td>


  <td>65
</td>

  <td>50
</td>

  <td>55
</td>

  <td>25
  /70
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro-based solution can be built to use command line and in-code annotations
to determine contract behavior.  P1607 and a macro-only facility would both
be able to provide any form of behavior control that users might wish to build, with
more consistency to the behaviors that different options might give with P1607.</p>
<p>N4820 and P1429 contract control is much more limited, primarily being only
doable at the build level of granularity.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>8</td>
  <td><a name="dev.adapt">dev.adapt</a></td>
  <td>Developer</td>
  <td>Adapt and progress with my project</td>
  <td>Be able to easily change my confidence, importance, or other properties of my
annotations over time</td>


  <td>40
</td>

  <td>25
</td>

  <td>50
</td>

  <td>25
  /75
</td>
</tr>


<tr>
  <td colspan="9"> <p>The build-level supporting options (N4820 and P1429) allow changing the one
attribute they expose (cost).   The macro-based solutions would have to build
support for this, but can clearly put that in the sou rce code and thus make
editing the attributes of an annotation easy to edit.</p>
<p>An important thing to note is that safely changing annotation properties in
released software is equivalent to introducing that contract freshly in any
deployments that ignored the old 'level' and check the new 'level'.  The ability
to introduce the check at the new 'level' with a continuing semantic is
essential to safely adding any checks to already deployed software.  N4820 and P1429
both only allow the control of continuation at a very high level, thus forcing a
user to turn continuation on for all existing checks in order to safely add checks
that continue.  P1607 provides the granularity to change this decision on a
per-contract basis.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>9</td>
  <td><a name="dev.readable.syntax">dev.readable.syntax</a></td>
  <td>Developer</td>
  <td>Have readable annotations</td>
  <td>Have annotations with a succinct and elegant syntax</td>


  <td>40
</td>

  <td>80
</td>

  <td>80
</td>

  <td>70
</td>
</tr>

  <tr>
  <td>10</td>
  <td><a name="dev.parsable">dev.parsable</a></td>
  <td>Developer</td>
  <td>Interoperate with tools or persons</td>
  <td>A syntax that can both be parsed and can be reasoned about semantically</td>


  <td>40
</td>

  <td>75
</td>

  <td>75
</td>

  <td>70
</td>
</tr>

  <tr>
  <td>11</td>
  <td><a name="cppdev.syntax.familiar">cppdev.syntax.familiar</a></td>
  <td>C++ Developer</td>
  <td>Get up to speed</td>
  <td>Have annotations use familiar syntax</td>


  <td>50
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>12</td>
  <td><a name="cppdev.syntax.cpp">cppdev.syntax.cpp</a></td>
  <td>C++ Developer</td>
  <td>Get up to speed</td>
  <td>Have annotations use C++ syntax</td>


  <td>50
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>13</td>
  <td><a name="cppdev.syntax.reuse">cppdev.syntax.reuse</a></td>
  <td>C++ Developer</td>
  <td>Reuse code</td>
  <td>Have annotations use my custom types or functions</td>


  <td>75
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>14</td>
  <td><a name="cppdev.location">cppdev.location</a></td>
  <td>C++ Developer</td>
  <td>Have a single source of truth</td>
  <td>Use same source file for both code and annotations</td>


  <td>100
</td>

  <td>100
</td>

  <td>100
</td>

  <td>100
</td>
</tr>


<tr>
  <td colspan="9"> <p>Obviously N4820 provides no explicit syntax and is limited to macros, but that
still allows for using readable C++ in the annotations.</p>
<p>P1607 likely requires macros to facilitate any global controls over behavior,
so is a slightly worse syntactic option than what N4820 and P1429 provide (which
have identical syntax).</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>15</td>
  <td><a name="dev.readable.keywords">dev.readable.keywords</a></td>
  <td>Developer</td>
  <td>Have readable annotations</td>
  <td>Have annotation keywords or names with intuitive, clear, and unambiguous
meanings</td>


  <td>10
</td>

  <td>50
</td>

  <td>50
</td>

  <td>60
</td>
</tr>


<tr>
  <td colspan="9"> <p>Given that it provides no new keywords for contracts, readability is going to be
entirely dependent on what macro based facility is being used with N4842.</p>
<p>For N4820 and P1429, the clarity of 'default' is fairly opaque, and a huge
amount of reflector discussion and contention has revolved around the meaning and
use of axiom, so they fair poorly here.</p>
<p>P1607 removes the contentious keywords, but introduces new bespoke keywords
that while clear are not necessarily intuitive to all, along with needing to
build any other controls on top of those with macros, so it seems only slightly
better in this regard.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>16</td>
  <td><a name="dev.readable.priority">dev.readable.priority</a></td>
  <td>Developer</td>
  <td>Have readable annotations</td>
  <td>Have my contract specification to be visually primary, and secondary
information (syntax, hints, roles, levels, etc.) to not be distracting</td>


  <td>15
</td>

  <td>10
</td>

  <td>10
</td>

  <td>10
</td>
</tr>


<tr>
  <td colspan="9"> <p>All of the attribute-based solutions put the meta-information first before the
expression, counter to what this use case is asking for.  A macro-based solution
could choose to prioritize information differently, but would also be
restricted in how the information gets passed into the macro.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>17</td>
  <td><a name="dev.tooling">dev.tooling</a></td>
  <td>Developer</td>
  <td>Interoperate with tools or persons</td>
  <td>Expose annotations to tools that might leverage them (eg. code linter, static
analyzer, semantic prover, compiler sanitizer, binary analyzer, code reviewer,
etc.)</td>


  <td>0
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>Entirely macro-based facilities would need to be ubiquitous enough for tooling
vendors to choose to support them explicitly, along with those tooling vendors
needing to work around the difficulties of managing pre-preprocessor based
analysis.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>18</td>
  <td><a name="cppdev.syntax.macros">cppdev.syntax.macros</a></td>
  <td>C++ Developer</td>
  <td>Support modern features</td>
  <td>Minimize use of macros</td>


  <td>0
</td>

  <td>50
</td>

  <td>60
</td>

  <td>50
  /0
</td>
</tr>


<tr>
  <td colspan="9"> <p>Obviously not very much can be done with the base language without macros.</p>
<p>P1607 would require macros to support any form of global controls, so it gets
the lowest rating for this use case, while P4820 would be usable for basic
applications without macros, and P1429 would be slightly more flexible without
needing to resort to macros.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>19</td>
  <td><a name="cppdev.modules">cppdev.modules</a></td>
  <td>C++ Developer</td>
  <td>Support modern features</td>
  <td>Be interoperable with modules</td>


  <td>10
</td>

  <td>25
</td>

  <td>25
</td>

  <td>25
</td>
</tr>


<tr>
  <td colspan="9"> <p>A purely macro based solution would have the worst interaction with modules.</p>
<p>The language-based solutions were expected to have basic support for modules,
since all would have landed in C++20, but no specific modules-related features
were initially planned.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>20</td>
  <td><a name="cppdev.coroutines">cppdev.coroutines</a></td>
  <td>C++ Developer</td>
  <td>Support modern features</td>
  <td>Be interoperable with coroutines</td>


  <td>25
</td>

  <td>25
</td>

  <td>25
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>21</td>
  <td><a name="api.coroutines">api.coroutines</a></td>
  <td>C++ API Developer</td>
  <td>Use coroutines</td>
  <td>Define and check pre and post conditions as I would a regular function</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>22</td>
  <td><a name="api.coroutines.invariants">api.coroutines.invariants</a></td>
  <td>C++ API Developer</td>
  <td>Use coroutines</td>
  <td>Define and check invariants over all entry and exit points from a coroutine (to
its awaiter or promise)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>All of the solutions would work perfectly fine within the body of a coroutine.
Coroutine handling of contracts on inputs, outputs, and states when resuming
a coroutine had not had any discussions or support planned in the proposals
as they existed, so none of the proposals support coroutines any better than
a purely macro-based solution.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>23</td>
  <td><a name="cppdev.concepts">cppdev.concepts</a></td>
  <td>C++ Developer</td>
  <td>Support modern features</td>
  <td>Be interoperable with concepts</td>


  <td>25
</td>

  <td>25
</td>

  <td>25
</td>

  <td>25
</td>
</tr>


<tr>
  <td colspan="9"> <p>Nothing about the prior facilities seems to benefit or hinder the use of
concepts.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>24</td>
  <td><a name="cppdev.existing.std">cppdev.existing.std</a></td>
  <td>C++ Developer</td>
  <td>Use the standard library in-contract</td>
  <td>Codify existing exposition-only standard library requirements</td>


  <td>50
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>Many of the preconditions and postconditions of the standard library can be
expressed as boolean expressions, and so are encodable using the facilities
that were provided.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>25</td>
  <td><a name="cppdev.debugger">cppdev.debugger</a></td>
  <td>C++ Developer</td>
  <td>Use Debugger</td>
  <td>Have runtime able to launch a debugger from an annotation if necessary</td>


  <td>25
</td>

  <td>40
</td>

  <td>40
</td>

  <td>40
</td>
</tr>


<tr>
  <td colspan="9"> <p>As much as any C++ program is able to do something like signal that a debugger
should be opened, a macro based solution could invoke the platform-specific
functions that would enable that (such as <code>__debugbreak()</code> or <code>raise(SIGTRAP)</code>).
All of the prior solutions also provided a consistent place to put such a function
call by allowing for setting a custom violation handler, and due to that being
globally consistent we rate them slightly higher.</p>
<p>This is still not a standardized facility, so no solution completely satisfies
this use case within the standard itself.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>26</td>
  <td><a name="cppdev.build.legacy">cppdev.build.legacy</a></td>
  <td>C++ Developer</td>
  <td>Use existing build modes</td>
  <td>Have annotations affect executions depending on my existing build modes (eg.
Debug or Release modes in VS)</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
  /10
</td>
</tr>


<tr>
  <td colspan="9"> <p>Those solutions that would use macros to do global control (N4842 and P1607)
would be able to reference _NDEBUG or similar macros usually associated with
"debug" and "release" builds as input to how they configure contracts.  The
standard, and the build levels specified in N4820 and P1429, are however
completely disconnected from one another.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>27</td>
  <td><a name="cdev.contracts">cdev.contracts</a></td>
  <td>C Developer</td>
  <td>Write contracts on my functions</td>
  <td>Specify contracts in a way standardizable as part of the C language</td>


  <td>10
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>28</td>
  <td><a name="cdev.identifiers">cdev.identifiers</a></td>
  <td>C Developer</td>
  <td>Write contracts on my functions</td>
  <td>Use contracts with macro-safe keywords that are reserved C names (i.e., _Pre,
_Post, _Assert, etc.)</td>


  <td>10
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>None of the contract specifications as a language feature would have been
palatable to the C standards committee, since they all require being able to
attach meaning to an attribute, as well as make use of new identifiers with
special meaning (which are unfriendly to standardize in the macro-heavy C
world.)</p>
<p>A pure C++ macro based contract solution would, however, possibly be
implementable in a fashion that is equally usable from C code.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>29</td>
  <td><a name="cdev.violationhandler">cdev.violationhandler</a></td>
  <td>C Developer</td>
  <td>Write contracts on my functions</td>
  <td>Have a common violation handler for both violated C and C++ contracts</td>


  <td>50
</td>

  <td>25
</td>

  <td>25
</td>

  <td>25
</td>
</tr>


<tr>
  <td colspan="9"> <p>With no C interoperability easily possible, and the violation handler specified
in terms of an opaque class type (<code>std::contract_violation</code>), implementing
that violation handler i C would not have been feasible.</p>
<p>It is, however, likely that any C-based contract solution would be able to
bridge to and from the C++ contract violation handler, since there is no
particularly complex functionality in the violation handler or the violation
object itself.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>30</td>
  <td><a name="cdev.ignorable">cdev.ignorable</a></td>
  <td>C Developer</td>
  <td>Write contracts on my functions</td>
  <td>Make all contract semantics optional (so as not to change WG14-N2385 6.7.11 p2)</td>


  <td>50
</td>

  <td>25
</td>

  <td>25
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>P1607's explicit semantics require that they behave in a specific way when
asked for.  Similarly, there is an expectation with N4820 and P1429 that build
levels can be set to something other than <code>off</code>, but they do allow global control
to do that (so at least one potential program behavior would be buildable
without needing to make contract annotations do anything).</p>
<p>Obviously a macro-based solution would be able to provide this kind of feature.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>31</td>
  <td><a name="ccppdev.interop">ccppdev.interop</a></td>
  <td>Mixed C/C++ Developer</td>
  <td>Maintain mixed code base</td>
  <td>Not lose contracts when crossing languages</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>32</td>
  <td><a name="cdev.cppinterop">cdev.cppinterop</a></td>
  <td>Mixed C/C++ Developer</td>
  <td>Write contracts on my functions</td>
  <td>Expose my contracts to C++ developers through 'extern "C"' declarations of my
functions</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>A pure macro-based facility exposes no contracts to callers, regardless of what
language the callers are calling from.  The language-based facilities would not
have readily supported standardizing by WG14.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>33</td>
  <td><a name="api.communicate.inputsoutputs">api.communicate.inputsoutputs</a></td>
  <td>API Developer</td>
  <td>Communicate my interface to users</td>
  <td>Document the expected inputs and expected outputs on my interface</td>


  <td>25
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>34</td>
  <td><a name="api.establish.check">api.establish.check</a></td>
  <td>API Developer</td>
  <td>Establish a contract</td>
  <td>Have validation inform me which output values are unexpected or invalid</td>


  <td>25
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>35</td>
  <td><a name="api.establish.values">api.establish.values</a></td>
  <td>API Developer</td>
  <td>Establish a contract</td>
  <td>Have validation inform user which input values are unexpected or invalid</td>


  <td>25
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>36</td>
  <td><a name="api.establish.preconditions">api.establish.preconditions</a></td>
  <td>API Developer</td>
  <td>Establish a contract</td>
  <td>Have contracts specify their pre-conditions as logical predicates</td>


  <td>25
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>37</td>
  <td><a name="api.establish.postconditions">api.establish.postconditions</a></td>
  <td>API Developer</td>
  <td>Establish a contract</td>
  <td>Have contracts specify their post-conditions as logical predicates</td>


  <td>25
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>Precondition and postcondition checks within  a function do something to document
inputs and outputs, as do comments that are readily available without a language
feature.</p>
<p>The language proposals all included the common feature of <code>[[pre]]</code> and
<code>[[post]]</code> to express this information directly on function declarations, and
have those get checked at runtime.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>38</td>
  <td><a name="api.establish.validate_invariants">api.establish.validate_invariants</a></td>
  <td>API Developer</td>
  <td>Establish a contract</td>
  <td>Have validation inform me which class invariants are violated</td>


  <td>5
</td>

  <td>5
</td>

  <td>5
</td>

  <td>5
</td>
</tr>

  <tr>
  <td>39</td>
  <td><a name="api.establish.invariants">api.establish.invariants</a></td>
  <td>API Developer</td>
  <td>Establish a contract</td>
  <td>Have contracts specify their class invariants as logical predicates</td>


  <td>5
</td>

  <td>5
</td>

  <td>5
</td>

  <td>5
</td>
</tr>

  <tr>
  <td>40</td>
  <td><a name="cppapi.invariants">cppapi.invariants</a></td>
  <td>C++ API Developer</td>
  <td>Write classes</td>
  <td>Declare class invariants that all of my public functions need to maintain</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>Neither a macro based facility or the language proposals allowed for specifying
at a class level invariants that would be automatically checked (barring
manually adding class invariants as pre and post conditions on every single
function.)</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>41</td>
  <td><a name="api.express.values">api.express.values</a></td>
  <td>API Developer</td>
  <td>Express predicates</td>
  <td>Make reference to either the values of my inputs, or other in-scope identifiers</td>


  <td>75
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>42</td>
  <td><a name="api.establish.changedvalues">api.establish.changedvalues</a></td>
  <td>API Developer</td>
  <td>Establish a contract</td>
  <td>Make reference to the before and after values of in-out variables (ie. passed
by pointer or reference) in post-conditions</td>


  <td>40
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>43</td>
  <td><a name="api.establish.changedmembers">api.establish.changedmembers</a></td>
  <td>API Developer</td>
  <td>Establish a contract</td>
  <td>Make reference to the before and after values of mutable class members (eg.
<i>new_size = old_size+1</i> after push_back) in post-conditions</td>


  <td>40
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>44</td>
  <td><a name="api.establish.changedstate">api.establish.changedstate</a></td>
  <td>API Developer</td>
  <td>Establish a contract</td>
  <td>Make reference to the before and after values of global state (eg., <i>global
&gt;= old(global) + 1</i>) in post-conditions</td>


  <td>40
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro based facility can similarly expose macros to control the enablement of
arbitrary code at arbitrary scopes, and so enables storing values between calling
time and return time manually.</p>
<p>The language-based facilities allow for referencing inputs and outputs, with
the caveat that inputs were only referencable in outputs if they were not
changed.  The language-based facilities explicitly prevented any form of making
additional code execute if contracts were enabled, and thus removed the ability
to store data between the start and end of a function call.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>45</td>
  <td><a name="api.extend.exceptionsafety">api.extend.exceptionsafety</a></td>
  <td>API Developer</td>
  <td>Extend contractual aspects</td>
  <td>Annotate operations as being exception safe</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>46</td>
  <td><a name="api.extend.threadsafety">api.extend.threadsafety</a></td>
  <td>API Developer</td>
  <td>Extend contractual aspects</td>
  <td>Annotate operations as being thread safe</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>47</td>
  <td><a name="api.extend.atomicity">api.extend.atomicity</a></td>
  <td>API Developer</td>
  <td>Extend contractual aspects</td>
  <td>Annotate operations as being atomic (ie. all or no changes become visible)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>48</td>
  <td><a name="api.extend.realtime">api.extend.realtime</a></td>
  <td>API Developer</td>
  <td>Extend contractual aspects</td>
  <td>Annotate operations as real-time (ie. guaranteed to complete within a time
frame)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>49</td>
  <td><a name="api.extend.determinism">api.extend.determinism</a></td>
  <td>API Developer</td>
  <td>Extend contractual aspects</td>
  <td>Annotate operations as being deterministic (ie. same outputs for same inputs)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>50</td>
  <td><a name="api.extend.purity">api.extend.purity</a></td>
  <td>API Developer</td>
  <td>Extend contractual aspects</td>
  <td>Annotate operations as functionally pure (ie. no side effects)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>51</td>
  <td><a name="api.extend.sideeffects">api.extend.sideeffects</a></td>
  <td>API Developer</td>
  <td>Extend contractual aspects</td>
  <td>Annotate operations as having global side effects (ie. write to singleton,
file, network, or database)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>52</td>
  <td><a name="api.extend.complexity">api.extend.complexity</a></td>
  <td>API Developer</td>
  <td>Extend contractual aspects</td>
  <td>Annotate algorithmic complexity</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>No codification of these features is baked into the language itself or added
by the previous proposals.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>53</td>
  <td><a name="api.express.runnability">api.express.runnability</a></td>
  <td>API Developer</td>
  <td>Express unrunnable contracts</td>
  <td>Be able to use a predicate that is not evaluated at runtime, because it might
be unsafe to run or have stateful side effects</td>


  <td>0
</td>

  <td>0
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>54</td>
  <td><a name="api.express.undefined">api.express.undefined</a></td>
  <td>API Developer</td>
  <td>Express unrunnable contracts</td>
  <td>Be able to use a predicate that doesn't have a definition, because it hasn't
been written yet, or is infeasible to run</td>


  <td>0
</td>

  <td>0
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>55</td>
  <td><a name="api.express.uncheckable">api.express.uncheckable</a></td>
  <td>API Developer</td>
  <td>Express uncheckable contracts</td>
  <td>Be able to use a predicate that is not evaluated, because it is simply a
semantic placeholder for a tool</td>


  <td>0
</td>

  <td>0
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>56</td>
  <td><a name="api.express.unimplementable">api.express.unimplementable</a></td>
  <td>API Developer</td>
  <td>Express uncheckable contracts</td>
  <td>Be able to use a predicate that cannot have a complete definition, because it
is inexpressible in the language</td>


  <td>0
</td>

  <td>0
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>There is no current in-language way to express predicates that will not be
executed at runtime.</p>
<p>N4820 had unchecked contracts leave their evaluation as unspecified, thus making
any predicate that has UB or has side effects potentially evaluated
(specifically, the wording said "it is unspecified if the predicate of an
unchecked contract is evaluated".)</p>
<p>P1429 and P1607's assume semantic, however, attempted to capture the original
intent of the contract proposals and make unchecked contracts not be evaluated,
thus enabling the use of predicates that are not themselves safe to ever
evaluate.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>57</td>
  <td><a name="api.establish.responsibility">api.establish.responsibility</a></td>
  <td>API Developer</td>
  <td>Establish responsibility boundaries</td>
  <td>Inform users which errors are the responsibility of the caller, and which are
the callee</td>


  <td>0
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
</td>
</tr>

  <tr>
  <td>58</td>
  <td><a name="api.resp.preassert">api.resp.preassert</a></td>
  <td>API Developer</td>
  <td>Establish responsibility boundaries</td>
  <td>Annotate assertions inside function bodies that indirectly test preconditions
(such as malformed data discovered while performing the algorithm) should be
reported to the caller as precondition failures</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>Macros within a function are unable to readily gather information about what
called the function, thus making it infeasible to identify calling code in a
precondition violation in a wholely macro-based facility.</p>
<p>N4820 made it possible to change that for <code>[[pre]]</code> annotations on a function
declaration, allowing for the reported source line to be the calling location
if the implementation is willing and able to do so.   There was, however, still
no facility to explicitly point at a caller being the source of a problem
when the problem gets detected within the body of a function (or, for instance,
when delegating to another function without duplicating that function's
preconditions explicitly).</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>59</td>
  <td><a name="api.contract.interface">api.contract.interface</a></td>
  <td>API Developer</td>
  <td>Have contract as part of my interface</td>
  <td>Declare contract when I declare the function</td>


  <td>0
</td>

  <td>100
</td>

  <td>100
</td>

  <td>100
</td>
</tr>


<tr>
  <td colspan="9"> <p>This is not doable with macros, but was inherent in the proposed contract
solutions.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>60</td>
  <td><a name="api.contract.private">api.contract.private</a></td>
  <td>API Developer</td>
  <td>Keep my user interfaces clean and narrow</td>
  <td>Be able to access private implementation details of the class so I don't have
to widen public interface to declare predicates</td>


  <td>100
</td>

  <td>100
</td>

  <td>100
</td>

  <td>100
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro within a function has full access to private data members of that
function's class, as do contracts in all of the language contract proposals.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>61</td>
  <td><a name="api.contract.redeclaration">api.contract.redeclaration</a></td>
  <td>API Developer</td>
  <td>Keep my public interfaces clean and concise</td>
  <td>Place function contract conditions on any declaration (e.g., on redeclarations
at the bottom of the header, or on the definition in an implementation file,
where they are less distracting).</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro-based facility obviously has no contracts on any declarations.  The
language based proposals did not allow for contracts on any declaration except
the first one.</p>
<p>Note that <a href="http://wg21.link/P1320R1">P1320R1</a> was going to be presented in
cologne and sought to alter this state.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>62</td>
  <td><a name="api.contract.errorhandling">api.contract.errorhandling</a></td>
  <td>API Developer</td>
  <td>Move contract violation out of error handling</td>
  <td>Replace uses of error handling to express contract violation (eg.
<i>operator[](size_t n) noexcept [[pre: n &lt; size()]]</i> instead of
throwing)</td>


  <td>50
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>This is a design decision when defining an API that could be readily
accomplished with any contract facility.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>63</td>
  <td><a name="cppapi.class.preconditions">cppapi.class.preconditions</a></td>
  <td>C++ API Developer</td>
  <td>Maintain a class hierarchy</td>
  <td>Ensure overriding methods have same or wider preconditions (see: Liskov
substitution principle)</td>


  <td>0
</td>

  <td>40
</td>

  <td>40
</td>

  <td>40
</td>
</tr>

  <tr>
  <td>64</td>
  <td><a name="cppapi.class.postconditions">cppapi.class.postconditions</a></td>
  <td>C++ API Developer</td>
  <td>Maintain a class hierarchy</td>
  <td>Ensure overriding functions meet their base class postconditions when their
base class preconditions are met (see: Liskov substitution principle)</td>


  <td>0
</td>

  <td>40
</td>

  <td>40
</td>

  <td>40
</td>
</tr>

  <tr>
  <td>65</td>
  <td><a name="cppapi.class.variability">cppapi.class.variability</a></td>
  <td>C++ API Developer</td>
  <td>Maintain a class hierarchy.</td>
  <td>Allow overriding functions to have narrower preconditions/wider postconditions
if I want to</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>A wholely macro based facility has no way to automatically integrate with
function overrides.</p>
<p>The language proposals all required that virtual functions have exactly the same
preconditions and postconditions, and so allowed for a subset of what would be
Liskov substitutable.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>66</td>
  <td><a name="api.class.publicinterface">api.class.publicinterface</a></td>
  <td>C++ API Developer</td>
  <td>Express public class invariants</td>
  <td>Express a restriction on the public interface of a type that all callers of the
type can depend upon: can mention only public members, and is checked on entry
and exit from this type's code</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>67</td>
  <td><a name="api.class.publicinvariants">api.class.publicinvariants</a></td>
  <td>C++ API Developer</td>
  <td>Express public class invariants</td>
  <td>Check invariants before and after every public method (when called from outside
the type, not when one member function calls another)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>68</td>
  <td><a name="api.class.publiccalls">api.class.publiccalls</a></td>
  <td>C++ API Developer</td>
  <td>Express public class invariants</td>
  <td>Check invariants before and after calling functions that are not part of this
type (including virtual calls)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>69</td>
  <td><a name="api.class.baseinterface">api.class.baseinterface</a></td>
  <td>C++ API Developer</td>
  <td>Express base class invariants</td>
  <td>Express a restriction on the protected interface of a type that derived types
can depend upon: can mention only protected and public members, and is checked
on entry and exit from this type's code</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>70</td>
  <td><a name="api.class.baseinvariants">api.class.baseinvariants</a></td>
  <td>C++ API Developer</td>
  <td>Express base class invariants</td>
  <td>Check invariants on entry and exit of every protected method (when called from
the derived type, not when one base member function calls another)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>71</td>
  <td><a name="api.class.basecalls">api.class.basecalls</a></td>
  <td>C++ API Developer</td>
  <td>Express base class invariants</td>
  <td>Check invariants before and after every call to a virtual function (when
calling to the derived type)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>72</td>
  <td><a name="api.class.privateinterface">api.class.privateinterface</a></td>
  <td>C++ API Developer</td>
  <td>Express private class invariants</td>
  <td>Express an internal restriction on the private implementation of a type, can
mention any member, and is checked on entry and exit from this type's code</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>73</td>
  <td><a name="api.class.privateinvariants">api.class.privateinvariants</a></td>
  <td>C++ API Developer</td>
  <td>Express private class invariants</td>
  <td>Check invariants on entry and exit of every public method (when called from
outside the type, not when one member function calls another)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>74</td>
  <td><a name="api.class.privatecalls">api.class.privatecalls</a></td>
  <td>C++ API Developer</td>
  <td>Express private class invariants</td>
  <td>Check invariants before and after calling functions that are not part of this
type (including virtual calls)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro-based facility is not part of the declared interface to any class,
but only part of the implementation.</p>
<p>The language proposals were limited to functions but not types, and always had
private access.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>75</td>
  <td><a name="api.class.testing">api.class.testing</a></td>
  <td>C++ API Developer</td>
  <td>Test my classes</td>
  <td>For every member or friend function in my class, run my unit test framework
with checking enabled for every assertion at the point where it is written, and
check every postcondition at every non-exceptional exit, and test my class
invariants on entry and exit from this type's code</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>This level of control is not providable for macros or the language proposals.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>76</td>
  <td><a name="cppapi.contracts.async">cppapi.contracts.async</a></td>
  <td>C++ API Developer</td>
  <td>Enforce contracts in async code</td>
  <td>Express contracts on callbacks such as std::function, function pointers, or
references to functions, lambdas, or function objects</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>This would require contracts be part of a function type.   Macros are not even
part of a function declaration, let alone its type, and the previous language
proposals did not choose to make contracts part of a function type either.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>77</td>
  <td><a name="cppapi.contracts.exception">cppapi.contracts.exception</a></td>
  <td>C++ API Developer</td>
  <td>Enforce contracts in exception safe code</td>
  <td>Express contracts on exceptional exit</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>78</td>
  <td><a name="cppapi.variadic">cppapi.variadic</a></td>
  <td>C++ API Developer</td>
  <td>Use contracts with variadic templates</td>
  <td>Allow predicate (fold) expansion</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>Neither of these are viable on the.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>79</td>
  <td><a name="int.conform.violation">int.conform.violation</a></td>
  <td>Integration Developer</td>
  <td>Conform to a contract</td>
  <td>Be informed any time an interface's contract is violated</td>


  <td>25
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
</td>
</tr>

  <tr>
  <td>80</td>
  <td><a name="int.conform.postconditions">int.conform.postconditions</a></td>
  <td>Integration Developer</td>
  <td>Conform to a contract</td>
  <td>Verify results from a call are expected output values</td>


  <td>25
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>This is the purpose of a checked contract facility, though the granularity of
control to limit to or at least include a particular (or all) interface is
not there for all proposals.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>81</td>
  <td><a name="int.build.headeronly">int.build.headeronly</a></td>
  <td>Integration Developer</td>
  <td>Build multiple libraries</td>
  <td>Use contract-enabled header-only libraries</td>


  <td>50
</td>

  <td>100
</td>

  <td>100
</td>

  <td>100
</td>
</tr>

  <tr>
  <td>82</td>
  <td><a name="cpplib.headeronly">cpplib.headeronly</a></td>
  <td>C++ Library Developer</td>
  <td>Use templates</td>
  <td>Be able to ship header only library</td>


  <td>50
</td>

  <td>100
</td>

  <td>100
</td>

  <td>100
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro based facility is likely to depend on having a supporting library exist
to make customization and violation handling available.</p>
<p>Nothing about the proposed solutions required this (or, as a language facility,
a library got the supporting functionality needed for free from the compiler's
runtime environment).</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>83</td>
  <td><a name="int.build.binaries">int.build.binaries</a></td>
  <td>Integration Developer</td>
  <td>Build multiple libraries</td>
  <td>Use contract-enabled binary libraries</td>


  <td>100
</td>

  <td>100
</td>

  <td>100
</td>

  <td>100
</td>
</tr>


<tr>
  <td colspan="9">  </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>84</td>
  <td><a name="int.build.binarycounts">int.build.binarycounts</a></td>
  <td>Integration Developer</td>
  <td>Build multiple libraries</td>
  <td>Only be required to manage a small, common set of build/link configurations</td>


  <td>75
</td>

  <td>40
</td>

  <td>25
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>Policies on how many different builds are managed and deployed are entirely
up to users when the facility's controls are all done through macros (either
entirely in N4842 or on top of literal semantics in P1607).</p>
<p>N4820 includes 5 distinct build configurations that might be desired by clients
of a library, and P1429 increases that number to 32, though most are only
interesting in special cases and it is likely that individual vendors would find
a small set that are of actual interest to their clients.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>85</td>
  <td><a name="int.build.control">int.build.control</a></td>
  <td>Integration Developer</td>
  <td>Debug multiple libraries</td>
  <td>Enable checks only within a selected library</td>


  <td>50
</td>

  <td>35
</td>

  <td>35
</td>

  <td>50
</td>
</tr>

  <tr>
  <td>86</td>
  <td><a name="int.build.control2">int.build.control2</a></td>
  <td>Integration Developer</td>
  <td>Debug multiple libraries</td>
  <td>Enable checks on multiple libraries simultaneously</td>


  <td>50
</td>

  <td>35
</td>

  <td>35
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>The build levels are global, with conditional (and potentially no) support for
using mixed build levels across different libraries.  Macro based solutions are
viable as long as any individual contract always has the same meaning in different
translation units (without ODR violations).</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>87</td>
  <td><a name="int.debug.callsites">int.debug.callsites</a></td>
  <td>Integration Developer</td>
  <td>Debug multiple call sites</td>
  <td>Enable checks only on selected call sites</td>


  <td>0
</td>

  <td>25
</td>

  <td>25
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>None of the solutions allowed for a function to be called with different checking
levels without violating the ODR.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>88</td>
  <td><a name="int.violations.information">int.violations.information</a></td>
  <td>Integration Developer</td>
  <td>Correct failed checks</td>
  <td>Be informed what check failed, when, where, and how</td>


  <td>75
</td>

  <td>100
</td>

  <td>100
</td>

  <td>100
</td>
</tr>

  <tr>
  <td>89</td>
  <td><a name="int.violations.transmit">int.violations.transmit</a></td>
  <td>Integration Developer</td>
  <td>Correct failed checks</td>
  <td>Transmit check failure information in environment-specific ways (logs, email,
special hardware traps, popup windows, blazing sirens, etc).</td>


  <td>50
</td>

  <td>90
</td>

  <td>90
</td>

  <td>90
</td>
</tr>

  <tr>
  <td>90</td>
  <td><a name="int.violations.custom">int.violations.custom</a></td>
  <td>Integration Developer</td>
  <td>Correct failed checks</td>
  <td>Install custom violation handler where I can inject custom logic to trap errors</td>


  <td>50
</td>

  <td>90
</td>

  <td>90
</td>

  <td>90
</td>
</tr>

  <tr>
  <td>91</td>
  <td><a name="int.violations.common">int.violations.common</a></td>
  <td>Integration Developer</td>
  <td>Unify violation handling</td>
  <td>Be able to override how library violations are handled in the combined software
to point into my handling code</td>


  <td>50
</td>

  <td>90
</td>

  <td>90
</td>

  <td>90
</td>
</tr>


<tr>
  <td colspan="9"> <p>All of the facilities support checking contracts at runtime and being informed
of details of the violation.   The language proposals included a pluggable
violation handler, although compiler vendors were allowed to not make that
customizable.</p>
<p>A pure macro-based facility suffers from needing to do this for all of the
contract facilities that might be defined and used within a given fully
assembled program.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>92</td>
  <td><a name="int.violations.override">int.violations.override</a></td>
  <td>Integration Developer</td>
  <td>Be independent of build environment</td>
  <td>Be able to define and override violation handler via source code</td>


  <td>15
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>This might be doable with a fair bit of complexity in a macro-based facility,
and there was no support for this in the language proposals.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>93</td>
  <td><a name="int.build.minimize">int.build.minimize</a></td>
  <td>Integration Developer</td>
  <td>Minimize checking overhead</td>
  <td>Disable library postconditions, asserts, and invariants, without disabling
library preconditions (assuming the library is tested and stable and my code is
not)</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>94</td>
  <td><a name="int.control.build">int.control.build</a></td>
  <td>Integrated Software Provider</td>
  <td>Ensure the combined software is correct</td>
  <td>At build time, turn on and off what checking happens.</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>95</td>
  <td><a name="int.control.runtime">int.control.runtime</a></td>
  <td>Integrated Software Provider</td>
  <td>At runtime, control what checking happens.</td>
  <td>Turn checks on at run time</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>96</td>
  <td><a name="int.conrol.subsets.build">int.conrol.subsets.build</a></td>
  <td>Integrated Software Provider</td>
  <td>Ensure the combined software is correct</td>
  <td>Turn on any subset of individual (call site) checks on at build time</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>97</td>
  <td><a name="int.control.subsets.runtime">int.control.subsets.runtime</a></td>
  <td>Integrated Software Provider</td>
  <td>Ensure the combined software is correct</td>
  <td>Turn on any subset of individual (call site) checks on at run time</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>98</td>
  <td><a name="int.control.subsets">int.control.subsets</a></td>
  <td>Integrated Software Provider</td>
  <td>Ensure individual features are correct</td>
  <td>Have a way to audit (named or semantic) subsets of checks for various
deployments</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>99</td>
  <td><a name="int.testing.control">int.testing.control</a></td>
  <td>Integrated Software Provider</td>
  <td>Define "Code Under Test"</td>
  <td>Selectively enable checking for a set of functions which could name either an
individual function or an overload set</td>


  <td>15
</td>

  <td>0
</td>

  <td>0
</td>

  <td>15
</td>
</tr>

  <tr>
  <td>100</td>
  <td><a name="int.testing.controltypes">int.testing.controltypes</a></td>
  <td>Integrated Software Provider</td>
  <td>Define "Code Under Test"</td>
  <td>Selectively enable checking for a set of types and all their members</td>


  <td>15
</td>

  <td>0
</td>

  <td>0
</td>

  <td>15
</td>
</tr>

  <tr>
  <td>101</td>
  <td><a name="int.testing.transitivity">int.testing.transitivity</a></td>
  <td>Integrated Software Provider</td>
  <td>Define "Code Under Test"</td>
  <td>Selectively enable checking for a set of types and all their transitively
nested types and members</td>


  <td>5
</td>

  <td>0
</td>

  <td>0
</td>

  <td>5
</td>
</tr>

  <tr>
  <td>102</td>
  <td><a name="int.testing.modules">int.testing.modules</a></td>
  <td>Integrated Software Provider</td>
  <td>Define "Code Under Test"</td>
  <td>Selectively enable checking for a translation unit or module and all (non
transitive) types and functions within</td>


  <td>5
</td>

  <td>0
</td>

  <td>0
</td>

  <td>5
</td>
</tr>


<tr>
  <td colspan="9"> <p>Different forms of build and runtime control could be built into the macro-based
facilities with varying levels of difficulty.   N4820 and P1429 provided only a
global level of control, limiting greatly the ability to control contract enablement
at finer granularities.   Implementing some of these forms of granularity in
the preprocessor might, however, be very complicated.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>103</td>
  <td><a name="int.consistency">int.consistency</a></td>
  <td>Integrated Software Provider</td>
  <td>Ensure the combined software is correct</td>
  <td>Verify all annotations are globally consistent when integrated</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>There is no support for this form of checking on a macro-based facility, or from
the language proposals.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>104</td>
  <td><a name="int.build.common">int.build.common</a></td>
  <td>Integrated Software Provider</td>
  <td>Manage binary delivery</td>
  <td>Be able to use the same executable regardless of contract enforcement mode</td>


  <td>15
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>A C++20 based facility could determine checking based on runtime configuration
instead of only compile-time configuration.   The language proposals did not
allow for that.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>105</td>
  <td><a name="int.build.unchecked">int.build.unchecked</a></td>
  <td>Integrated Software Provider</td>
  <td>Test final deliverable</td>
  <td>Turn off build time checking to remove checking overhead</td>


  <td>40
</td>

  <td>50
</td>

  <td>50
</td>

  <td>40
</td>
</tr>

  <tr>
  <td>106</td>
  <td><a name="int.runtime.unchecked">int.runtime.unchecked</a></td>
  <td>Integrated Software Provider</td>
  <td>Test final deliverable</td>
  <td>Turn off run time checking to remove checking overhead</td>


  <td>50
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>Macros and the language proposals had minimal concepts of "build time checking",
but they do all enable a global ability to turn off such checking.  That same
global ability can be used to turn off runtime checking.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>107</td>
  <td><a name="int.build.optimize">int.build.optimize</a></td>
  <td>Integrated Software Provider</td>
  <td>Test final deliverable</td>
  <td>Turn on run time optimization to leverage annotation assumptions</td>


  <td>25
</td>

  <td>50
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>108</td>
  <td><a name="pdev.speed">pdev.speed</a></td>
  <td>Performance Sensitive Developer</td>
  <td>Enable better performance</td>
  <td>Annotate my code with assumptions, likelihoods, or reachability information
that a tool might not be able to deduce, but that I would be confident of</td>


  <td>25
</td>

  <td>50
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>109</td>
  <td><a name="pdev.morespeed">pdev.morespeed</a></td>
  <td>Performance Sensitive Developer</td>
  <td>Enable better performance</td>
  <td>Be able to give statically-unprovable facts to current and novel optimizers in
terms of semantics my program does not depend-on but optimizers can't figure
out</td>


  <td>25
</td>

  <td>50
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>110</td>
  <td><a name="pdev.footgun">pdev.footgun</a></td>
  <td>Performance Sensitive Developer</td>
  <td>Enable better performance</td>
  <td>Accept responsibility for a malformed program that might result from eventually
false information given by my annotations</td>


  <td>25
</td>

  <td>50
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro based facility would be able to enable optimizations, but that is likely
going to have limited direct support from most compilers.  (Generally, this would
leverage either <code>__unreachable()</code> or <code>__assume()</code>.)</p>
<p>N4820 made optimizations enabled for ALL unchecked contracts, while P1429 and P1607
gave mechanisms to opt into that in varying ways.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>111</td>
  <td><a name="cpplib.insulation">cpplib.insulation</a></td>
  <td>C++ Library Developer</td>
  <td>Control the tradeoff between need for client recompilation and contract condition visibility</td>
  <td>Insulate contract conditions with the function definition, or insulate only the
definition while putting contract conditions on a redeclaration - visible to
static analysis tools in all TUs.</td>


  <td>25
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>Macro based contract checks will always be in the function body and thus
fully insulated from clients.</p>
<p>The contract annotations of the language proposals could be equivalently put
in function bodies with <code>[[assert]]</code> or on the declarations, thus giving some
control over insulation.   The ability to have them visible to clients through
a redeclaration but not visible on the initial declaration was not, however,
in the initial proposals (but was proposed but not seen by EWG in
<a href="http://wg21.link/P1320R1">P1320R1</a>.)</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>112</td>
  <td><a name="lib.maintenance.noconfig">lib.maintenance.noconfig</a></td>
  <td>Library Provider</td>
  <td>Simplify maintenance</td>
  <td>Not require extra build steps to be documented</td>


  <td>25
</td>

  <td>25
</td>

  <td>25
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>113</td>
  <td><a name="lib.integration.noconfig">lib.integration.noconfig</a></td>
  <td>Library Provider</td>
  <td>Support successful integration</td>
  <td>Not require extra build steps to be learned or performed</td>


  <td>25
</td>

  <td>25
</td>

  <td>25
</td>

  <td>25
</td>
</tr>


<tr>
  <td colspan="9"> <p>Any contract facility that allows control without source code manipulation will
require some build time control, either through compiler flags or macros, though
all should have been usable with some default behavior if no explicit choices
were made at build time.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>114</td>
  <td><a name="lib.maintenance.nowhining">lib.maintenance.nowhining</a></td>
  <td>Library Provider</td>
  <td>Simplify maintenance</td>
  <td>Not have users complain about my product due to modifications of annotations
resulting from their build configuration</td>


  <td>75
</td>

  <td>0
</td>

  <td>0
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>115</td>
  <td><a name="lib.integration.nowhining">lib.integration.nowhining</a></td>
  <td>Library Provider</td>
  <td>Support successful integration</td>
  <td>Not have my users accidentally modify my careful annotations</td>


  <td>75
</td>

  <td>0
</td>

  <td>0
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro based facility could provide concrete semantics similar to P1607, thus
making contracts that cannot have their behavior changed from the command line.</p>
<p>N4820 and P1429 contracts are always subject to build modes, leaving no way to
enforce that a particular behavior is applied to a given contract annotation.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>116</td>
  <td><a name="arch.nomacros">arch.nomacros</a></td>
  <td>Technical Architect</td>
  <td>Maintain quality of code base</td>
  <td>Express assertions in a way that does not rely on C macros (i.e., there is no
valid technical reason for a programmer not to use the new way, including
space, time, tooling, and usability/complexity reasons, compared to C's assert
macro)</td>


  <td>0
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>Contract checks without a language facility are not feasibly doable without macros.</p>
<p>All of the language proposals require macros in some form or other to satisfy
many of the use cases in this document, but still provide a basic contract
checking facility with no macros used at all.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>117</td>
  <td><a name="arch.complete">arch.complete</a></td>
  <td>Technical Architect</td>
  <td>Have a consistent and holistic contracts facility</td>
  <td>Specify preconditions/postconditions/assertions/invariants that express my
expectations about the expected valid state of my program in the form of
compilable boolean expressions, that can be checked statically or dynamically
(as opposed to disjointed state where these features are factored into bits)</td>


  <td>0
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>Obviously the language does not have this now, and the language proposals all
attempted to provide this.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>118</td>
  <td><a name="hardware.performance">hardware.performance</a></td>
  <td>Hardware Architect</td>
  <td>Improve system-level performance</td>
  <td>Be able to design new hardware + optimizations, carefully dovetailed into one
another, that depend on statically-unprovable facts being annotated in the code</td>


  <td>0
</td>

  <td>25
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>N4820's inability to have contracts that are never executed prevents this from
being leveraged for many novel features.  P1429 and P1607's assume semantic
fixed this.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>119</td>
  <td><a name="sdev.bestpractices">sdev.bestpractices</a></td>
  <td>Senior Developer</td>
  <td>Set an example</td>
  <td>Demonstrate best practice in defensive programming</td>


  <td>50
</td>

  <td>25
</td>

  <td>50
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>Any basic contract checking facility can be used to implement defensive
programming.</p>
<p>N4820's implicit assumption of any unchecked contract, however, is unlikely to
ever be viewable as a best practice to use by anyone.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>120</td>
  <td><a name="sdev.quality">sdev.quality</a></td>
  <td>Senior Developer</td>
  <td>Enforce code quality</td>
  <td>Discourage reliance on observable out-of-contract behavior by causing check
failure to hard stop program or build</td>


  <td>50
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>This behavior is available in any of the facilities, though not as strongly
enforced when a user has control over the violation handler.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>121</td>
  <td><a name="sdev.maturity">sdev.maturity</a></td>
  <td>Senior Developer</td>
  <td>Enforce mature, finalized contracts</td>
  <td>Disable continuation on violation of stable and correct individual contracts</td>


  <td>50
</td>

  <td>25
</td>

  <td>25
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>122</td>
  <td><a name="sdev.control">sdev.control</a></td>
  <td>Senior Developer</td>
  <td>Enforce mature, finalized contracts</td>
  <td>Disable remapping of semantics on stable and correct individual contracts</td>


  <td>50
</td>

  <td>25
</td>

  <td>25
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>The global controls of N4820 and P1429 do not allow for control over an individual
contract's behavior (continuing or not, checked or not) based on the maturity of that
specific contract.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>123</td>
  <td><a name="jdev.understand.contracts">jdev.understand.contracts</a></td>
  <td>Junior Developer</td>
  <td>Understand the API</td>
  <td>A uniform, fluent description of expected input values, expected output values,
side effects, and all logical pre and post conditions</td>


  <td>0
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>124</td>
  <td><a name="jdev.understand.violations">jdev.understand.violations</a></td>
  <td>Junior Developer</td>
  <td>Understand the API</td>
  <td>Be informed when my usage is out of contract</td>


  <td>50
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>125</td>
  <td><a name="jdev.understand.buildfailures">jdev.understand.buildfailures</a></td>
  <td>Junior Developer</td>
  <td>Understand the program</td>
  <td>Know why my software is not building</td>


  <td>50
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>126</td>
  <td><a name="jdev.understand.aborting">jdev.understand.aborting</a></td>
  <td>Junior Developer</td>
  <td>Understand the program</td>
  <td>Know why my software is aborting</td>


  <td>50
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>127</td>
  <td><a name="jdev.understand.omniscience">jdev.understand.omniscience</a></td>
  <td>Junior Developer</td>
  <td>Understand the program</td>
  <td>Know why my software is out of contract</td>


  <td>50
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>128</td>
  <td><a name="jdev.understand.buildviolation">jdev.understand.buildviolation</a></td>
  <td>Junior Developer</td>
  <td>Understand the program</td>
  <td>Know that my program or build was halted due to contract violation</td>


  <td>50
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>129</td>
  <td><a name="jdev.bestpractices">jdev.bestpractices</a></td>
  <td>Junior Developer</td>
  <td>Improve my code</td>
  <td>Learn about software best practices by example</td>


  <td>50
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>Without a language feature contract descriptions are library-specific and not
uniform.  With it, the only non-uniformity comes in when libraries build
extra infrastructure on top of the language-provided facility.</p>
<p>A library and a language-based facility will, however, be able to provide
a user understandable details of why a contract violation might have made a
program abort or fail to compile.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>130</td>
  <td><a name="jdev.understand.all">jdev.understand.all</a></td>
  <td>Junior Developer</td>
  <td>Understand the facility</td>
  <td>Be able to build a program with contracts after reasonably short tutorial</td>


  <td>50
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>Whether with a library or any of the proposed language features, simple contract
use remains simple.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>131</td>
  <td><a name="jdev.understand.keywords">jdev.understand.keywords</a></td>
  <td>Junior Developer</td>
  <td>Understand the facility</td>
  <td>Have keywords with precise and unambiguous meanings</td>


  <td>0
</td>

  <td>25
</td>

  <td>25
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>Without a language feature there are no new keywords.  N4820 and P1429 include
<code>axiom</code> which has shown to have significant disagreement over what meaning it
has in the context of contracts (see <a href="http://wg21.link/P1672R0">P1672</a>).</p>
<p>The keywords provided by P1607 are all very precisely defined.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>132</td>
  <td><a name="adev.fast">adev.fast</a></td>
  <td>Agile Developer</td>
  <td>Iterate quickly</td>
  <td>Be able to write and modify contracts quickly without heavy boiler plate or up
front cost</td>


  <td>0
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>The general use of contracts once they are a language feature is quick to get
started on.   Without a language feature, getting started requires acquiring or
implementing a library to provide the feature.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>133</td>
  <td><a name="adev.evolve">adev.evolve</a></td>
  <td>Agile Developer</td>
  <td>Safeguard evolving code</td>
  <td>Assert against conditions I am aware of but not finished handling fully</td>


  <td>20
</td>

  <td>0
</td>

  <td>0
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>Without a language-based facility the only way to enter a not-yet-implemented
contract is as a comment, which is of limited utility.</p>
<p>P1607's ignore and assume semantics both allow for referencing undefined functions,
and thus enable writing a planned contract while preserving writing the
implementation of that check for a future sprint.   N4820 provides no way
to get that semantic for a contract annotation, and while P1429's assume semantic
would, there is no way in code to write such a contract.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>134</td>
  <td><a name="bdev.confidentiality">bdev.confidentiality</a></td>
  <td>Business Developer</td>
  <td>Maintain confidentiality</td>
  <td>Not expose diagnostic information (source location, expressions, etc.) in the
software I deliver to clients, even when I choose to have contracts enforced in
the software I deliver</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro-based library could choose to forgo including this information, or
provide flags to control that.</p>
<p>None of the language features proposed include that ability.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>135</td>
  <td><a name="pdev.safety.isolation">pdev.safety.isolation</a></td>
  <td>Performance Sensitive Developer</td>
  <td>Have safety critical paths</td>
  <td>Isolate safety checks from performance annotations</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro-based library could provide this distinction.  None of the language
proposals include this, and importantly all of them allow for a contract to
be assumed and thus subvert any future "safety checks" that attempt to handle
out-of-contract behavior more elegantly.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>136</td>
  <td><a name="pdev.safety.critical">pdev.safety.critical</a></td>
  <td>Performance Sensitive Developer</td>
  <td>Have safety critical paths</td>
  <td>Retain checking even when optimizing with performance annotations</td>


  <td>25
</td>

  <td>0
</td>

  <td>15
</td>

  <td>20
</td>
</tr>


<tr>
  <td colspan="9"> <p>N4820 provides no way to turn checking off locally without bringing in assumption.
P1429 at least provides a way to build an application without assumption of checks,
and macro-based solutions on top of P1607 or a fully-macro based solution would be
able to allow for this kind of distinction with some effort.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>137</td>
  <td><a name="qdev.checkall">qdev.checkall</a></td>
  <td>Quality Sensitive Developer</td>
  <td>Enable full checking</td>
  <td>Ensure all checks (pre, post, assert, invariant) are enabled</td>


  <td>25
</td>

  <td>100
</td>

  <td>100
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>138</td>
  <td><a name="qdev.fuzz.testing">qdev.fuzz.testing</a></td>
  <td>Quality Sensitive Developer</td>
  <td>Catch unexpected failure modes</td>
  <td>Log all predicate failure during fuzz testing</td>


  <td>25
</td>

  <td>100
</td>

  <td>100
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>A disparate set of macro-based libraries makes it hard to turn on all checking.</p>
<p>N4820 and P1429 allow for this to be done very easily with build modes.  P1607
allows for code to subvert this kind of control by providing explicit semantics
for a particular contract that cannot be externally altered.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>139</td>
  <td><a name="qdev.correctness">qdev.correctness</a></td>
  <td>Quality Sensitive Developer</td>
  <td>Validate correctness</td>
  <td>Signify the predicates that should be verified by an analysis tool</td>


  <td>25
</td>

  <td>50
</td>

  <td>50
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>140</td>
  <td><a name="qdev.tooling">qdev.tooling</a></td>
  <td>Quality Sensitive Developer</td>
  <td>Manage multiple tools</td>
  <td>Signify subset of individual annotations to be consumed by a specific kind of
verification tool</td>


  <td>25
</td>

  <td>50
</td>

  <td>50
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>141</td>
  <td><a name="qdev.tooling.control">qdev.tooling.control</a></td>
  <td>Quality Sensitive Developer</td>
  <td>Manage multiple tools</td>
  <td>Signify subset of individual annotations to be consumed by a specific instance
of verification tool</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>25
</td>
</tr>


<tr>
  <td colspan="9"> <p>It can be argued that the primary intention of <code>axiom</code> was to only provide information
to static analysis tools, so both of the proposals that include that have that here, even though
the wording itself added in undefined behavior to that level, and made no mention of this purpose.</p>
<p>A macro-based facility could integrate with a static analysis tool for this purpose,
but would require tools to choose to support it.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>142</td>
  <td><a name="qdev.tooling.undefined">qdev.tooling.undefined</a></td>
  <td>Quality Sensitive Developer</td>
  <td>Manage multiple tools</td>
  <td>Use predicates that may not be understood by all instances of verification</td>


  <td>0
</td>

  <td>0
</td>

  <td>25
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>143</td>
  <td><a name="qdev.tooling.undefinedkinds">qdev.tooling.undefinedkinds</a></td>
  <td>Quality Sensitive Developer</td>
  <td>Manage multiple tools</td>
  <td>Use predicates that may not be understood by all kinds of verification</td>


  <td>0
</td>

  <td>0
</td>

  <td>25
</td>

  <td>25
</td>
</tr>


<tr>
  <td colspan="9"> <p>Only P1429 and P1607 allow predicates to remain undefined if not referenced
and not checked at runtime.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>144</td>
  <td><a name="qdev.tooling.behavior">qdev.tooling.behavior</a></td>
  <td>Quality Sensitive Developer</td>
  <td>Manage multiple tools</td>
  <td>Integrate the results of that static checker into how my program behaves in
different ways: assume proven predicates, make unprovable predicates ill-
formed, etc.</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>25
</td>
</tr>


<tr>
  <td colspan="9"> <p>P1607 or a wholely macro-based facility provide the only direct way to integrate
the results of analysis into specific behaviors for contract checks.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>145</td>
  <td><a name="qdev.testing">qdev.testing</a></td>
  <td>Quality Sensitive Developer</td>
  <td>Unit test predicates</td>
  <td>Override failure handler to trigger test failure instead of termination</td>


  <td>25
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>All of the proposals included a conditionally supported custom violation handler
which could be used to test that checks are actually checked at runtime in a unit
test (at least, for noexcept functions).   A macro-based facility can accomplish
this as well (and this is the foundation of all negative testing in BDE, see
<a href="https://bbgithub.dev.bloomberg.com/bde/bde/blob/master/groups/bsl/bsls/bsls_asserttest.h">bsls_asserttest.h</a>
for an example of how that might be implemented).</p>
<p>Importantly, the lack of by-default runtime changing of violation handler behavior
means that a custom violation handler must be written to get the full functionality
needed - when testing that a check is violated, you want the violation handler to
throw so you can recover to do more tests, while when testing anything else you
want a hard error because a bug has been found by your testing.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>146</td>
  <td><a name="qdev.handler.testing">qdev.handler.testing</a></td>
  <td>Quality Sensitive Developer</td>
  <td>Unit test violation handlers</td>
  <td>Have a way to run handler on all combinations of available build modes</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>The proposal in N4820 and all of its descendants prohibited any way to
directly invoke the violation handler.  A macro-based facility can expose this
with relative ease (and, for example, BDE does with the macro <code>BSLS_ASSERT_INVOKE</code>).</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>147</td>
  <td><a name="crit.control">crit.control</a></td>
  <td>Critical Software Developer</td>
  <td>Have a verifiable release system</td>
  <td>Be able to control the configuration of contracts from a central point</td>


  <td>25
</td>

  <td>75
</td>

  <td>75
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro based facility, or macros built on top of P1607, could provide this -
with the major limitation that there might be multiple such facilities to
configure within a single application.</p>
<p>N4820 and P1429 only provide global controls over how contracts behave.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>148</td>
  <td><a name="crit.noundef">crit.noundef</a></td>
  <td>Critical Software Developer</td>
  <td>Avoid undefined behavior</td>
  <td>Have contract violation at run-time always have well-defined behavior</td>


  <td>25
</td>

  <td>0
</td>

  <td>75
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>Only P1429 allows removing any use of an <code>assume</code>-like semantic from contracts.
A macro-based facility can choose to provide that (using various forms of
non-portable or semi-portable implementations).   N4820 provides no way to
turn off contract checks without them introducing undefined behavior.</p>
<p>P1607 Allows for this, but also allows for the explicit use of the <code>assume</code>
semantic when desired, which does not allow for altering how it behaves.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>149</td>
  <td><a name="crit.recovery">crit.recovery</a></td>
  <td>Critical Software Developer</td>
  <td>Not have a faulty program lead to catastrophic failure</td>
  <td>Have access to a recovery path after contract violation</td>


  <td>25
</td>

  <td>0
</td>

  <td>75
</td>

  <td>50
</td>
</tr>

  <tr>
  <td>150</td>
  <td><a name="crit.redundancy">crit.redundancy</a></td>
  <td>Critical Software Developer</td>
  <td>Not have a faulty program lead to catastrophic failure</td>
  <td>Be able to express error handling that may be redundant with contract checking</td>


  <td>25
</td>

  <td>0
</td>

  <td>75
</td>

  <td>50
</td>
</tr>

  <tr>
  <td>151</td>
  <td><a name="crit.interaction">crit.interaction</a></td>
  <td>Critical Software Developer</td>
  <td>Not have a faulty program lead to catastrophic failure</td>
  <td>Not have contract build or run modes possibly be able to change or disable
related error handling in any way</td>


  <td>25
</td>

  <td>0
</td>

  <td>75
</td>

  <td>50
</td>
</tr>

  <tr>
  <td>152</td>
  <td><a name="crit.testing">crit.testing</a></td>
  <td>Critical Software Developer</td>
  <td>Meet code coverage requirements</td>
  <td>Be able to run both success and failure branches in my test environment</td>


  <td>25
</td>

  <td>0
</td>

  <td>75
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>With the right build or diligently avoiding the use of the <code>assume</code> semantic
recovery paths work properly after violations, although the check itself would
need to be duplicated.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>153</td>
  <td><a name="crit.locality">crit.locality</a></td>
  <td>Critical Software Developer</td>
  <td>Be assured a critical violation uses a critical recovery path</td>
  <td>Couple recovery path to a specific contract within the source</td>


  <td>25
</td>

  <td>10
</td>

  <td>10
</td>

  <td>10
</td>
</tr>


<tr>
  <td colspan="9"> <p>The only viable option with the language proposals would be a custom violation
handler that access a diligently updated thread-local recovery path when there
is a violation.  There is no innate support for this built into the facilities.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>154</td>
  <td><a name="crit.production.checking">crit.production.checking</a></td>
  <td>Critical Software Developer</td>
  <td>Have redundant layering</td>
  <td>Be able to continue to run checks in a production environment (even after
formal testing is complete)</td>


  <td>25
</td>

  <td>50
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>P1429 gives complete flexibility about what levels are checked or not in the
builds you choose to deploy to production.  P1607 and a macro-based facility
allow building that same kind of functionality.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>155</td>
  <td><a name="crit.more.coverage">crit.more.coverage</a></td>
  <td>Critical Software Developer</td>
  <td>Maximize coverage</td>
  <td>Be able to run checks in a production environment that are considered "cheap"
compared to the expected cost of entering an invalid state</td>


  <td>25
</td>

  <td>75
</td>

  <td>75
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>N4820 and P1429 both explicitly consider cost as the primary metadata that can
be put on a contract annotation (via a level of <code>default</code> or <code>audit</code>).  This
doesn't allow for any more granularity in that expression of cost, but it is</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>156</td>
  <td><a name="crit.noassume">crit.noassume</a></td>
  <td>Critical Software Developer</td>
  <td>Avoid unexpected or undefined behavior</td>
  <td>Ensure checks will never be __assume'd/__builtin_assume'd by the compiler as if
they were facts injected into the program (otherwise, if such an assumption
ever failed, I would be running a different program that is not equivalent to
the one I wrote; assumptions can expand the set of possible executions by
injecting facts not otherwise knowable to the compiler)</td>


  <td>0
</td>

  <td>0
</td>

  <td>50
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>Only P1429 provides the a way to configure contract annotations to never
be assumed.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>157</td>
  <td><a name="sec.noattacks">sec.noattacks</a></td>
  <td>Security Sensitive Developer</td>
  <td>Limit attack vectors</td>
  <td>Be unable to insert code paths (eg. violation handlers) at run time (eg. build
time only)</td>


  <td>0
</td>

  <td>90
</td>

  <td>90
</td>

  <td>90
</td>
</tr>


<tr>
  <td colspan="9"> <p>None of the contract facilities allow any runtime alteration of the violation
handler.</p>
<p>Note importantly that an application may choose to install a custom violation
handler that delegates to something that is runtime controllable, so this
restriction is circumventable if the compiler allows for setting a custom
violation handler.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>158</td>
  <td><a name="sec.certify">sec.certify</a></td>
  <td>Security Sensitive Developer</td>
  <td>Deliver a certified product</td>
  <td>Have build tool only link to a preapproved violation handler</td>


  <td>0
</td>

  <td>90
</td>

  <td>90
</td>

  <td>90
</td>
</tr>


<tr>
  <td colspan="9"> <p>The wording for N4820 and its derivatives allows for a compiler to choose to not
allow for changing the violation handler to something user defined.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>159</td>
  <td><a name="analysis.runtime">analysis.runtime</a></td>
  <td>User of Analysis Tools</td>
  <td>Improve runtime correctness</td>
  <td>Have runtime checks generated by the tool</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>50
</td>
</tr>

  <tr>
  <td>160</td>
  <td><a name="analysis.optimization">analysis.optimization</a></td>
  <td>User of Analysis Tools</td>
  <td>Improve runtime performance</td>
  <td>Have runtime optimizations generated by the tool</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>None of the proposals or the language itself support direct integration with a
static analysis tool.   Explicit literal semantics, however, could be injected
into code by such a tool to generate computed contract behavior - runtime checking,
optimizations, or otherwise.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>161</td>
  <td><a name="analysis.symbolic">analysis.symbolic</a></td>
  <td>User of Analysis Tools</td>
  <td>Allow symbolic analysis</td>
  <td>Have symbolic proofs for soundness and consistency performed before compile
time</td>


  <td>25
</td>

  <td>50
</td>

  <td>75
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>162</td>
  <td><a name="analysis.compiletime">analysis.compiletime</a></td>
  <td>User of Analysis Tools</td>
  <td>Allow code analysis</td>
  <td>Have code source, AST, or instruction inspection during compile time</td>


  <td>25
</td>

  <td>50
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>Proofs of soundness are certainly aided by stating contract annotations and
asking for validation of those annotations.   Tooling will need to catch up
to leverage this and do such proving.</p>
<p>Many such proofs rely on being able to state additional facts that are not easy
to codify as boolean checks, and those are often needed to thoroughly prove
even much simpler predicates, so none of the proposed solutions are complete
for this purpose.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>163</td>
  <td><a name="analysis.binaries">analysis.binaries</a></td>
  <td>User of Analysis Tools</td>
  <td>Allow binary analysis</td>
  <td>Have binary inspection after compile time</td>


  <td>0
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>In principle contract checks could be carried forwarded and recorded in binaries
to allow for post-compile verification.  It seems unlikely that a non-builtin
facility would be standardized in binary files in such a way.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>164</td>
  <td><a name="analysis.information">analysis.information</a></td>
  <td>User of Analysis Tools</td>
  <td>Improve the quality of analysis</td>
  <td>Be able to hint to the analyzer information it may be unable to deduce from
source code alone (eg. <i>5 / opaque(); [[ opaque() != 0]]</i>)</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>None of the proposals allow for hints that are exclusively for the static
analyzer to use, but the P1607 <code>ignore</code> semantic could be used for such a
purpose.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>165</td>
  <td><a name="analysis.legacy">analysis.legacy</a></td>
  <td>Provider of Analysis Tools</td>
  <td>Extend my existing engine</td>
  <td>Be able to map pre-existing contract features in tools to a standardized
language syntax</td>


  <td>0
</td>

  <td>25
</td>

  <td>25
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>166</td>
  <td><a name="large.modernize">large.modernize</a></td>
  <td>Large Codebase Owner</td>
  <td>Modernize my code base</td>
  <td>Introduce standardized contracts to replace my macro-based contracts</td>


  <td>0
</td>

  <td>25
</td>

  <td>25
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>Only a very limited legacy framework (such as the C <code>assert</code> macro)
that completely falls within the functionality
provided by N4820 would be migratable without drastic changes in behavior.</p>
<p>P1607 sought to provide more flexibility for reimplementing most legacy frameworks
in terms of common semantics provided by the language.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>167</td>
  <td><a name="teach.bestpractices">teach.bestpractices</a></td>
  <td>Teacher</td>
  <td>Demonstrate best practice</td>
  <td>Be able to express defensive programming, programming by contract, and test
driven development to introductory students</td>


  <td>25
</td>

  <td>100
</td>

  <td>100
</td>

  <td>100
</td>
</tr>

  <tr>
  <td>168</td>
  <td><a name="teach.standardized">teach.standardized</a></td>
  <td>Teacher</td>
  <td>Demonstrate best practice</td>
  <td>Not rely on custom libraries or proprietary extensions</td>


  <td>0
</td>

  <td>100
</td>

  <td>100
</td>

  <td>100
  /50
</td>
</tr>

  <tr>
  <td>169</td>
  <td><a name="teach.lifecycle">teach.lifecycle</a></td>
  <td>Teacher</td>
  <td>Demonstrate best practice</td>
  <td>Demonstrate mock lifecycle by switching simple compiler flags to control which
checks are enabled</td>


  <td>0
</td>

  <td>50
</td>

  <td>50
</td>

  <td>25
  /75
</td>
</tr>

  <tr>
  <td>170</td>
  <td><a name="teach.portable">teach.portable</a></td>
  <td>Teacher</td>
  <td>Manage many students</td>
  <td>Have examples compilable by a standard compiler on any system</td>


  <td>0
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
  /40
</td>
</tr>


<tr>
  <td colspan="9"> <p>Basic defensive programming is directly expressable through any of the proposed
contract facilities.   Without a language feature, custom libraries must be used
and that is not portable.</p>
<p>Advanced features of contract lifecycle are more difficult to teach when not
directly supported, and none of the proposals provide a complete solution for
that behavior (see <a href="http://wg21.link/P1332R0">P1332</a> for a broad discussion of
what sorts of lifecycle considerations impact contract use), while only
P1607 provides a way to do so at all at a non-global granularity.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>171</td>
  <td><a name="teach.dumbstudents">teach.dumbstudents</a></td>
  <td>Teacher</td>
  <td>Manage many students</td>
  <td>Have examples that are easy to build without digression into build systems</td>


  <td>0
</td>

  <td>50
</td>

  <td>40
</td>

  <td>30
</td>
</tr>


<tr>
  <td colspan="9"> <p>More advanced usages with P1429 or P1607 are clearly dependent on more
complicated configuration.   N4820 provides a simple set of flags (build modes) that would
arguably be easiest to teach and use.</p>
<p>Note that nothing in P1429 prevented the support for the same set of build
modes in addition to the more specific semantic per level setting that it
required.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>172</td>
  <td><a name="teach.teachable">teach.teachable</a></td>
  <td>Teacher</td>
  <td>Build layers of understanding</td>
  <td>Have simple explanation of assertions and their use to support simple
programming tasks, including debugging erroneous programs.</td>


  <td>0
</td>

  <td>50
</td>

  <td>50
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>173</td>
  <td><a name="teach.layering">teach.layering</a></td>
  <td>Teacher</td>
  <td>Build layers of understanding</td>
  <td>Support the ability for advanced uses of contracts to be distributed across
many different courses in a C++-focused computer science curriculum.</td>


  <td>0
</td>

  <td>50
</td>

  <td>50
</td>

  <td>75
  /50
</td>
</tr>


<tr>
  <td colspan="9"> <p>N4820 and P1429 provide the least advanced features, but all of the proposals
allow for basic contract use to be done (<code>default</code> level contract annotations)
without any knowledge of the more advanced options that might be available.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>174</td>
  <td><a name="compiler.benice">compiler.benice</a></td>
  <td>Compiler Developer</td>
  <td>Deliver best experience to my customers</td>
  <td>Maximize implementation freedom by limiting what is strictly required by the
standard</td>


  <td>0
</td>

  <td>40
</td>

  <td>40
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>The explicit specification of build modes seems to be seen as highly restrictive
by compiler vendors, and the less specific the standard is about that
aspect of the facility the more this user base seems to be satisfied.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>175</td>
  <td><a name="compiler.best">compiler.best</a></td>
  <td>Compiler Developer</td>
  <td>Deliver the best implementation</td>
  <td>Have a clear and simple specification that meets clear need</td>


  <td>0
</td>

  <td>15
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>N4820 had many open questions about its specification where it had diverged
from the original contract proposals.  The semantic presentation in P1429 and
P1607  sought to be very precise about what was expected of program behavior
for any given contract.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>176</td>
  <td><a name="large.complex">large.complex</a></td>
  <td>Large Codebase Developer</td>
  <td>Debug complex issues</td>
  <td>Have composable and fine grained control over which checks are run, without
requiring source code changes. Specifically the checks for only one function or
some grouping of functions</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>177</td>
  <td><a name="large.critical">large.critical</a></td>
  <td>Large Codebase Developer</td>
  <td>Enable/Disable checking on critical/hot paths</td>
  <td>Control whether checks are run based on where they are being called from</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>A macro based facility could build this form of subsetting with a great deal of
effort, though callsite based checking does not seem feasible in any macro based
facility.  N4820 and P1429 provide no fine grained control of checks.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>178</td>
  <td><a name="large.stillmacros">large.stillmacros</a></td>
  <td>Large Codebase Owner</td>
  <td>Modernize my code base</td>
  <td>Have my existing macro-based facilities interoperate smoothly with standardized
contracts so I can do the migration gradually</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>Only by mapping to literal semantics could a more advanced contract facility be
able to maintain behaviors while still using the same underlying facility that
the language provides.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>179</td>
  <td><a name="large.observation">large.observation</a></td>
  <td>Large Codebase Owner</td>
  <td>Introduce new contracts into an existing system</td>
  <td>Have failed individual checks from existing code optionally warn instead of
hard stop</td>


  <td>25
</td>

  <td>25
</td>

  <td>25
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>180</td>
  <td><a name="large.introduction">large.introduction</a></td>
  <td>Large Codebase Owner</td>
  <td>Introduce new contracts into an existing system</td>
  <td>Have failed checks from a new library optionally warn instead of hard stop</td>


  <td>25
</td>

  <td>25
</td>

  <td>50
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>181</td>
  <td><a name="large.newenvironment">large.newenvironment</a></td>
  <td>Large Codebase Owner</td>
  <td>Introduce new elements into a contracts based system</td>
  <td>Have failed checks caused by a change in environment optionally warn instead of
hard stop</td>


  <td>25
</td>

  <td>25
</td>

  <td>50
</td>

  <td>75
</td>
</tr>

  <tr>
  <td>182</td>
  <td><a name="large.newcompiler">large.newcompiler</a></td>
  <td>Large Codebase Owner</td>
  <td>Introduce new elements into a contracts based system</td>
  <td>Have failed checks caused by a change in compiler optionally warn instead of
hard stop</td>


  <td>25
</td>

  <td>25
</td>

  <td>50
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>N4820 and P1429 provide a continuation mode to be able to make this decision
at a global (or translation unit) scope.  P1607 provides the ability to do
this per-contract.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>183</td>
  <td><a name="large.separability">large.separability</a></td>
  <td>Large Codebase Owner</td>
  <td>Introduce new parameters or invariants into a contracts based system</td>
  <td>Be able to include distinct clauses for each parameter or invariant with their
own individual failure or build controls</td>


  <td>25
</td>

  <td>75
</td>

  <td>75
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>All of the language proposals allowed for multiple distinct annotations on a
single function.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>184</td>
  <td><a name="large.nogoingback">large.nogoingback</a></td>
  <td>Large Codebase Owner</td>
  <td>Prevent regressions</td>
  <td>Have trusted contracts fail fast and hard stop</td>


  <td>25
</td>

  <td>0
</td>

  <td>10
</td>

  <td>75
</td>
</tr>


<tr>
  <td colspan="9"> <p>The global controls of N4820 and P1429 limit the ability to enforce only those
checks that are trusted, and provide no natural way to mix some continuing contracts with
some non-continuing contracts.  (P1429 would allow this by assigning different
semantics to <code>audit</code> and <code>default</code> level contracts, but that would conflict with the
intended distinction between those levels based on cost of checking.)</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>185</td>
  <td><a name="large.scalability">large.scalability</a></td>
  <td>Large Codebase Owner</td>
  <td>Scale violation handling</td>
  <td>Be able to log violations in my organization specific format</td>


  <td>25
</td>

  <td>90
</td>

  <td>90
</td>

  <td>90
</td>
</tr>


<tr>
  <td colspan="9"> <p>All of the proposals with a global pluggable violation handler allow this
form of customization, though it is not required by any that a compiler actually
allow the customization of the violation handler.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>186</td>
  <td><a name="large.simulation.disable">large.simulation.disable</a></td>
  <td>Large Codebase Owner</td>
  <td>Allow simulation or post-mortem testing of known failure modes</td>
  <td>Optionally disable checking on a subset of individual annotations</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>187</td>
  <td><a name="large.simulation.enable">large.simulation.enable</a></td>
  <td>Large Codebase Owner</td>
  <td>Allow simulation or post-mortem testing of known failure modes</td>
  <td>Optionally allow checking of a subset of individual annotations to fail and
access its recovery path</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>25
</td>
</tr>

  <tr>
  <td>188</td>
  <td><a name="large.simulation.ignore">large.simulation.ignore</a></td>
  <td>Large Codebase Owner</td>
  <td>Allow simulation or post-mortem testing of known failure modes</td>
  <td>Optionally allow checking of a subset of individual annotations to fail and
continue failing</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>25
</td>
</tr>


<tr>
  <td colspan="9"> <p>Subsets of annotations can be called out with macro-based solutions, but not with the
global controls of N4820 or P1429.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>189</td>
  <td><a name="large.perfcontrol.build">large.perfcontrol.build</a></td>
  <td>Large Codebase Owner</td>
  <td>Manage performance cost</td>
  <td>Constrain the set of built time checks according to their performance overhead</td>


  <td>0
</td>

  <td>25
</td>

  <td>25
</td>

  <td>20
</td>
</tr>

  <tr>
  <td>190</td>
  <td><a name="large.perfcontrol.runtime">large.perfcontrol.runtime</a></td>
  <td>Large Codebase Owner</td>
  <td>Manage performance cost</td>
  <td>Constrain the set of runtime checks according to their performance overhead</td>


  <td>0
</td>

  <td>50
</td>

  <td>50
</td>

  <td>40
</td>
</tr>


<tr>
  <td colspan="9"> <p>The language proposals had minimal control over build-time checking, but were
focused on doing any constraining based on the cost of the check.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>191</td>
  <td><a name="large.narrowing">large.narrowing</a></td>
  <td>Large Codebase Owner</td>
  <td>Tune contract width in complex system</td>
  <td>Be able to narrow individual contract so it fails in testing not in production</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>A P1607 contract can have a macro to control individual semantics and go through
a lifecycle where it is checked or enforced in testing but left ignored in production.
Without global control, this cannot be done with N4820 or P1429.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>192</td>
  <td><a name="embedded.nochecking">embedded.nochecking</a></td>
  <td>Small Machine Developer</td>
  <td>Minimize executable footprint</td>
  <td>Remove all checking and diagnostic (eg. source location) overhead entirely from
the final binary</td>


  <td>25
</td>

  <td>50
</td>

  <td>50
</td>

  <td>50
</td>
</tr>


<tr>
  <td colspan="9"> <p>The language based proposals allow for the removal of checking without</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>193</td>
  <td><a name="embedded.nologging">embedded.nologging</a></td>
  <td>Small Machine Developer</td>
  <td>Minimize executable footprint</td>
  <td>Remove all logging and diagnostic (but not checking) overhead from the final
binary</td>


  <td>25
</td>

  <td>10
</td>

  <td>10
</td>

  <td>10
</td>
</tr>

  <tr>
  <td>194</td>
  <td><a name="embedded.minimize">embedded.minimize</a></td>
  <td>Small Machine Developer</td>
  <td>Minimize executable footprint</td>
  <td>Remove all but the most important diagnostic overhead from the final binary</td>


  <td>25
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>None of the proposals allow for total removal of logging information from
the generated code, while a macro based facility could support that option.</p>
<p>It would conceivable be possible for link time optimization to recognize that
a violation handler made no use of source information/did no logging and then
it would be able to remove that source information as well, but this would have
significant compile time overhead on a system.</p> </td>
</tr>
<tr><td colspan="9"/></tr>

  <tr>
  <td>195</td>
  <td><a name="wg21.everythingelse">wg21.everythingelse</a></td>
  <td>Language Developer</td>
  <td>Interoperate with Contracts</td>
  <td>Have a clear way to understand how contracts will interact with the standard
library</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>

  <tr>
  <td>196</td>
  <td><a name="wg21.otherfeatures">wg21.otherfeatures</a></td>
  <td>Language Developer</td>
  <td>Extend contracts beyond pre/post conditions on functions</td>
  <td>Be able to use contract-like syntax on past or present runtime checkable
language features such as switches, pattern matching, etc. or what might happen
on signed integer overflow, etc. This might allow configuration of trapping,
logging, or assuming in other areas of language UB.</td>


  <td>0
</td>

  <td>0
</td>

  <td>0
</td>

  <td>0
</td>
</tr>


<tr>
  <td colspan="9"> <p>None of the proposed solutions began integration with the rest of the standard,
though they would have facilitated it in various ways.</p> </td>
</tr>
<tr><td colspan="9"/></tr>


</table>

<br/>

<h2>Conclusion</h2>
<p>This is a lot of information to digest, so it might help to be able to get
some overview numbers on how the different proposals relate to one another.
There are endless ways to do this, and we make no attempt to be complete in
this analysis, but we will present some approaches that might be
useful.</p>
<ul>
<li>Simply adding up what percentage of the total value each proposal satisfies
produces the following results:</li>
</ul>
<table>
<thead>
<tr>
<th>Proposal</th>
<th>Score</th>
<th>Score W/Macros</th>
</tr>
</thead>
<tbody>
<tr>
<td>N4842</td>
<td>0.000%</td>
<td>22.041%</td>
</tr>
<tr>
<td>N4820</td>
<td>31.454%</td>
<td>31.454%</td>
</tr>
<tr>
<td>P1429</td>
<td>37.908%</td>
<td>37.908%</td>
</tr>
<tr>
<td>P1607</td>
<td>42.321%</td>
<td>43.087%</td>
</tr>
</tbody>
</table>
<ul>
<li>An alternative is to integrate the results of the initial polls that were
reported in <a href="http://wg21.link/P1995R0">P1995R0</a>, using those to weight
the scores provided above (i.e., the values in the "Score" column in that
paper):</li>
</ul>
<table>
<thead>
<tr>
<th>Proposal</th>
<th>Score</th>
<th>Score W/Macros</th>
</tr>
</thead>
<tbody>
<tr>
<td>N4842</td>
<td>0.000%</td>
<td>24.683%</td>
</tr>
<tr>
<td>N4820</td>
<td>38.306%</td>
<td>38.306%</td>
</tr>
<tr>
<td>P1429</td>
<td>44.703%</td>
<td>44.703%</td>
</tr>
<tr>
<td>P1607</td>
<td>48.847%</td>
<td>49.527%</td>
</tr>
</tbody>
</table>
<ul>
<li>Similarly, we could instead only consider the scores for use cases that had a
score in P1995R0 above a certain threshhold, such as everything with a score over
1.0:</li>
</ul>
<table>
<thead>
<tr>
<th>Proposal</th>
<th>Score</th>
<th>Score W/Macros</th>
</tr>
</thead>
<tbody>
<tr>
<td>N4842</td>
<td>0.000%</td>
<td>28.419%</td>
</tr>
<tr>
<td>N4820</td>
<td>48.156%</td>
<td>48.156%</td>
</tr>
<tr>
<td>P1429</td>
<td>54.359%</td>
<td>54.359%</td>
</tr>
<tr>
<td>P1607</td>
<td>57.940%</td>
<td>58.634%</td>
</tr>
</tbody>
</table>
<p>Note that these are not intended to produce a complete measure of those proposals,
but simply as an example of how they might be compared.   These totals are not
a good measure of which proposal is intrinsicly better, but the changes to these
totals from any individual proposal should be considered relevant when trying
to understand how all users might benefit from any perticular change.</p>

</body>
</html>

