<!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>P1995R0 &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: P1995R0 <br/>
Date: 2019-11-22 <br/>
Authors:
Joshua Berne,
Timur Doumler,
Andrzej Krzemie&#324;ski,
Ryan McDougall,
Herb Sutter
<br/>
Reply-to: jberne4@bloomberg.net <br/>
Audience: SG21</p>
<h1>Contracts &mdash; Use Cases</h1>
<h2>Introduction</h2>
<p>SG21 has gathered a large number of use cases for contracts between teh WG21
Cologne and Belfast meetings.  This paper presents those use cases, along
with some initial results from polling done of SG21 members to identify
some level of important to the community for each individual use case.</p>
<p>Each use case has been assigned an identifier that can be used to reference
these use cases in other papers, which will hopefully be stable.  We expect
this content to evolve in a number of ways:</p>
<ul>
<li>Long descriptions of these use cases (found at the bottom of this document)
could all benefit from additional contributions.</li>
<li>Future poll results, analysis of these poll results, and other analysis of
this data will help guide group decisions on further SG21 progress.</li>
<li>New and old contracts proposals, along with the current possibilities with
no language changes at all, should be explored and measured in relation to how
they satisfy these use cases.</li>
</ul>
<h2>Polling</h2>
<p>Polling occurred through SurveyMonkey between the July 2019 WG21 Cologne meeting
and the November 2019 WG21 Belfast meeting.   Participants were asked to choose
from three answers for each of the 195 different use cases:</p>
<ul>
<li>Must Have (Must = 2)</li>
<li>Nice to Have (Nice = 1)</li>
<li>Not important (Not = 0)</li>
</ul>
<p>Participants were also able to not answer at all for a given question (N/A),
and this happened for a small number of cases.  The table of use cases below
lists 4 columns with the total number of each response chosen.  The score column
is the average value of the responses amongst those who provided a response.</p>
  

<h2>All Use Cases and Poll Results</h2>

<table>
  <tr>
    <th>Code</th><th>As A</th><th>In Order To</th><th>I Want To</th>
    <th>N/A</th><th>Not</th><th>Nice</th><th>Must</th><th>Score</th>
  </tr>

<tr><td><a href="#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>0</td>
  <td>0</td>
  <td>10</td>
  <td>20</td>
  <td>
    1.666667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>10</td>
  <td>10</td>
  <td>10</td>
  <td>
    1.000000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>15</td>
  <td>10</td>
  <td>5</td>
  <td>
    0.666667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>12</td>
  <td>11</td>
  <td>
    1.133333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>9</td>
  <td>14</td>
  <td>
    1.233333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>3</td>
  <td>8</td>
  <td>19</td>
  <td>
    1.533333
    </td>
  </tr>

<tr><td><a href="#dev.reason.behaviorcontrol">dev.reason.behaviorcontrol</a></td>
  <td>Developer</td>
  <td>Reason about executions</td>
  <td>Have the effect of annotations on executions be user controllable (ie. decide
whether "cheap" checks or "critical" terminates)</td>
  <td>0</td>
  <td>4</td>
  <td>10</td>
  <td>16</td>
  <td>
    1.400000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>2</td>
  <td>17</td>
  <td>11</td>
  <td>
    1.300000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>0</td>
  <td>13</td>
  <td>17</td>
  <td>
    1.566667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>0</td>
  <td>11</td>
  <td>19</td>
  <td>
    1.633333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>17</td>
  <td>6</td>
  <td>
    0.966667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>1</td>
  <td>6</td>
  <td>23</td>
  <td>
    1.733333
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>9</td>
  <td>20</td>
  <td>
    1.633333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>12</td>
  <td>15</td>
  <td>3</td>
  <td>
    0.700000
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>8</td>
  <td>11</td>
  <td>10</td>
  <td>
    1.068966
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>1</td>
  <td>9</td>
  <td>20</td>
  <td>
    1.633333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>1</td>
  <td>4</td>
  <td>25</td>
  <td>
    1.800000
    </td>
  </tr>

<tr><td><a href="#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>5</td>
  <td>18</td>
  <td>7</td>
  <td>
    1.066667
    </td>
  </tr>

<tr><td><a href="#cppdev.modules">cppdev.modules</a></td>
  <td>C++ Developer</td>
  <td>Support modern features</td>
  <td>Be interoperable with modules</td>
  <td>0</td>
  <td>0</td>
  <td>6</td>
  <td>24</td>
  <td>
    1.800000
    </td>
  </tr>

<tr><td><a href="#cppdev.coroutines">cppdev.coroutines</a></td>
  <td>C++ Developer</td>
  <td>Support modern features</td>
  <td>Be interoperable with coroutines</td>
  <td>0</td>
  <td>3</td>
  <td>11</td>
  <td>16</td>
  <td>
    1.433333
    </td>
  </tr>

<tr><td><a href="#cppdev.concepts">cppdev.concepts</a></td>
  <td>C++ Developer</td>
  <td>Support modern features</td>
  <td>Be interoperable with concepts</td>
  <td>0</td>
  <td>3</td>
  <td>9</td>
  <td>18</td>
  <td>
    1.500000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>5</td>
  <td>18</td>
  <td>7</td>
  <td>
    1.066667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>10</td>
  <td>12</td>
  <td>8</td>
  <td>
    0.933333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>9</td>
  <td>13</td>
  <td>8</td>
  <td>
    0.966667
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>21</td>
  <td>6</td>
  <td>2</td>
  <td>
    0.344828
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>22</td>
  <td>6</td>
  <td>1</td>
  <td>
    0.275862
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>16</td>
  <td>11</td>
  <td>2</td>
  <td>
    0.517241
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>23</td>
  <td>3</td>
  <td>3</td>
  <td>
    0.310345
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>12</td>
  <td>14</td>
  <td>3</td>
  <td>
    0.689655
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>16</td>
  <td>12</td>
  <td>1</td>
  <td>
    0.482759
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>3</td>
  <td>5</td>
  <td>22</td>
  <td>
    1.633333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>2</td>
  <td>14</td>
  <td>14</td>
  <td>
    1.400000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>2</td>
  <td>14</td>
  <td>14</td>
  <td>
    1.400000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>1</td>
  <td>11</td>
  <td>18</td>
  <td>
    1.566667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>2</td>
  <td>3</td>
  <td>25</td>
  <td>
    1.766667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>5</td>
  <td>13</td>
  <td>12</td>
  <td>
    1.233333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>5</td>
  <td>5</td>
  <td>20</td>
  <td>
    1.500000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>2</td>
  <td>2</td>
  <td>26</td>
  <td>
    1.800000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>11</td>
  <td>12</td>
  <td>
    1.166667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>14</td>
  <td>9</td>
  <td>
    1.066667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>13</td>
  <td>14</td>
  <td>3</td>
  <td>
    0.666667
    </td>
  </tr>

<tr><td><a href="#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>13</td>
  <td>17</td>
  <td>0</td>
  <td>
    0.566667
    </td>
  </tr>

<tr><td><a href="#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>13</td>
  <td>17</td>
  <td>0</td>
  <td>
    0.566667
    </td>
  </tr>

<tr><td><a href="#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>15</td>
  <td>15</td>
  <td>0</td>
  <td>
    0.500000
    </td>
  </tr>

<tr><td><a href="#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>20</td>
  <td>9</td>
  <td>1</td>
  <td>
    0.366667
    </td>
  </tr>

<tr><td><a href="#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>11</td>
  <td>13</td>
  <td>6</td>
  <td>
    0.833333
    </td>
  </tr>

<tr><td><a href="#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>10</td>
  <td>15</td>
  <td>5</td>
  <td>
    0.833333
    </td>
  </tr>

<tr><td><a href="#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>13</td>
  <td>17</td>
  <td>0</td>
  <td>
    0.566667
    </td>
  </tr>

<tr><td><a href="#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>19</td>
  <td>11</td>
  <td>0</td>
  <td>
    0.366667
    </td>
  </tr>

<tr><td><a href="#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>6</td>
  <td>14</td>
  <td>10</td>
  <td>
    1.133333
    </td>
  </tr>

<tr><td><a href="#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>8</td>
  <td>12</td>
  <td>10</td>
  <td>
    1.066667
    </td>
  </tr>

<tr><td><a href="#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>8</td>
  <td>12</td>
  <td>10</td>
  <td>
    1.066667
    </td>
  </tr>

<tr><td><a href="#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>11</td>
  <td>9</td>
  <td>10</td>
  <td>
    0.966667
    </td>
  </tr>

<tr><td><a href="#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>4</td>
  <td>11</td>
  <td>15</td>
  <td>
    1.366667
    </td>
  </tr>

<tr><td><a href="#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>12</td>
  <td>13</td>
  <td>5</td>
  <td>
    0.766667
    </td>
  </tr>

<tr><td><a href="#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>3</td>
  <td>6</td>
  <td>21</td>
  <td>
    1.600000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>5</td>
  <td>12</td>
  <td>13</td>
  <td>
    1.266667
    </td>
  </tr>

<tr><td><a href="#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>12</td>
  <td>11</td>
  <td>7</td>
  <td>
    0.833333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>11</td>
  <td>12</td>
  <td>
    1.166667
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>4</td>
  <td>13</td>
  <td>12</td>
  <td>
    1.275862
    </td>
  </tr>

<tr><td><a href="#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>4</td>
  <td>20</td>
  <td>6</td>
  <td>
    1.066667
    </td>
  </tr>

<tr><td><a href="#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>2</td>
  <td>20</td>
  <td>8</td>
  <td>
    1.200000
    </td>
  </tr>

<tr><td><a href="#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>13</td>
  <td>14</td>
  <td>3</td>
  <td>
    0.666667
    </td>
  </tr>

<tr><td><a href="#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>9</td>
  <td>19</td>
  <td>2</td>
  <td>
    0.766667
    </td>
  </tr>

<tr><td><a href="#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>5</td>
  <td>21</td>
  <td>4</td>
  <td>
    0.966667
    </td>
  </tr>

<tr><td><a href="#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>8</td>
  <td>20</td>
  <td>2</td>
  <td>
    0.800000
    </td>
  </tr>

<tr><td><a href="#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>14</td>
  <td>15</td>
  <td>1</td>
  <td>
    0.566667
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>14</td>
  <td>13</td>
  <td>2</td>
  <td>
    0.586207
    </td>
  </tr>

<tr><td><a href="#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>10</td>
  <td>18</td>
  <td>2</td>
  <td>
    0.733333
    </td>
  </tr>

<tr><td><a href="#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>12</td>
  <td>14</td>
  <td>4</td>
  <td>
    0.733333
    </td>
  </tr>

<tr><td><a href="#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>9</td>
  <td>17</td>
  <td>4</td>
  <td>
    0.833333
    </td>
  </tr>

<tr><td><a href="#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>13</td>
  <td>15</td>
  <td>2</td>
  <td>
    0.633333
    </td>
  </tr>

<tr><td><a href="#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>10</td>
  <td>9</td>
  <td>11</td>
  <td>
    1.033333
    </td>
  </tr>

<tr><td><a href="#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>4</td>
  <td>21</td>
  <td>5</td>
  <td>
    1.033333
    </td>
  </tr>

<tr><td><a href="#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>11</td>
  <td>13</td>
  <td>6</td>
  <td>
    0.833333
    </td>
  </tr>

<tr><td><a href="#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>4</td>
  <td>15</td>
  <td>11</td>
  <td>
    1.233333
    </td>
  </tr>

<tr><td><a href="#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>4</td>
  <td>15</td>
  <td>11</td>
  <td>
    1.233333
    </td>
  </tr>

<tr><td><a href="#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>7</td>
  <td>19</td>
  <td>4</td>
  <td>
    0.900000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>2</td>
  <td>12</td>
  <td>16</td>
  <td>
    1.466667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>4</td>
  <td>9</td>
  <td>17</td>
  <td>
    1.433333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>0</td>
  <td>6</td>
  <td>24</td>
  <td>
    1.800000
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>1</td>
  <td>7</td>
  <td>21</td>
  <td>
    1.689655
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>6</td>
  <td>15</td>
  <td>9</td>
  <td>
    1.100000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>1</td>
  <td>14</td>
  <td>15</td>
  <td>
    1.466667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>2</td>
  <td>14</td>
  <td>14</td>
  <td>
    1.400000
    </td>
  </tr>

<tr><td><a href="#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>5</td>
  <td>18</td>
  <td>7</td>
  <td>
    1.066667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>1</td>
  <td>9</td>
  <td>20</td>
  <td>
    1.633333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>5</td>
  <td>14</td>
  <td>11</td>
  <td>
    1.200000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>9</td>
  <td>14</td>
  <td>
    1.233333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>6</td>
  <td>9</td>
  <td>15</td>
  <td>
    1.300000
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>14</td>
  <td>11</td>
  <td>4</td>
  <td>
    0.655172
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>8</td>
  <td>14</td>
  <td>8</td>
  <td>
    1.000000
    </td>
  </tr>

<tr><td><a href="#int.control.build">int.control.build</a></td>
  <td>Integrated Software Provider</td>
  <td>Ensure the combined software is correct</td>
  <td>Turn checks on at build time</td>
  <td>0</td>
  <td>3</td>
  <td>6</td>
  <td>21</td>
  <td>
    1.600000
    </td>
  </tr>

<tr><td><a href="#int.control.runtime">int.control.runtime</a></td>
  <td>Integrated Software Provider</td>
  <td>Ensure the combined software is correct</td>
  <td>Turn checks on at run time</td>
  <td>0</td>
  <td>14</td>
  <td>11</td>
  <td>5</td>
  <td>
    0.700000
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>8</td>
  <td>12</td>
  <td>9</td>
  <td>
    1.034483
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>15</td>
  <td>12</td>
  <td>3</td>
  <td>
    0.600000
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>6</td>
  <td>20</td>
  <td>3</td>
  <td>
    0.896552
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>9</td>
  <td>16</td>
  <td>4</td>
  <td>
    0.827586
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>16</td>
  <td>10</td>
  <td>4</td>
  <td>
    0.600000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>11</td>
  <td>16</td>
  <td>3</td>
  <td>
    0.733333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>12</td>
  <td>15</td>
  <td>3</td>
  <td>
    0.700000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>13</td>
  <td>14</td>
  <td>3</td>
  <td>
    0.666667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>6</td>
  <td>19</td>
  <td>5</td>
  <td>
    0.966667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>9</td>
  <td>6</td>
  <td>15</td>
  <td>
    1.200000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>3</td>
  <td>5</td>
  <td>22</td>
  <td>
    1.633333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>6</td>
  <td>12</td>
  <td>12</td>
  <td>
    1.200000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>1</td>
  <td>4</td>
  <td>25</td>
  <td>
    1.800000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>11</td>
  <td>13</td>
  <td>6</td>
  <td>
    0.833333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>14</td>
  <td>10</td>
  <td>6</td>
  <td>
    0.733333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>17</td>
  <td>9</td>
  <td>4</td>
  <td>
    0.566667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>13</td>
  <td>13</td>
  <td>4</td>
  <td>
    0.700000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>12</td>
  <td>11</td>
  <td>7</td>
  <td>
    0.833333
    </td>
  </tr>

<tr><td><a href="#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>7</td>
  <td>13</td>
  <td>10</td>
  <td>
    1.100000
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>3</td>
  <td>12</td>
  <td>14</td>
  <td>
    1.379310
    </td>
  </tr>

<tr><td><a href="#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>2</td>
  <td>8</td>
  <td>10</td>
  <td>10</td>
  <td>
    1.071429
    </td>
  </tr>

<tr><td><a href="#sdev.bestpractices">sdev.bestpractices</a></td>
  <td>Senior Developer</td>
  <td>Set an example</td>
  <td>Demonstrate best practice in defensive programming</td>
  <td>0</td>
  <td>3</td>
  <td>9</td>
  <td>18</td>
  <td>
    1.500000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>8</td>
  <td>6</td>
  <td>16</td>
  <td>
    1.266667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>4</td>
  <td>7</td>
  <td>19</td>
  <td>
    1.500000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>9</td>
  <td>12</td>
  <td>9</td>
  <td>
    1.000000
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>15</td>
  <td>14</td>
  <td>
    1.433333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>0</td>
  <td>9</td>
  <td>21</td>
  <td>
    1.700000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>3</td>
  <td>6</td>
  <td>21</td>
  <td>
    1.600000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>1</td>
  <td>9</td>
  <td>20</td>
  <td>
    1.633333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>1</td>
  <td>11</td>
  <td>18</td>
  <td>
    1.566667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>0</td>
  <td>7</td>
  <td>23</td>
  <td>
    1.766667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>4</td>
  <td>12</td>
  <td>14</td>
  <td>
    1.333333
    </td>
  </tr>

<tr><td><a href="#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>2</td>
  <td>13</td>
  <td>15</td>
  <td>
    1.433333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>4</td>
  <td>12</td>
  <td>14</td>
  <td>
    1.333333
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>14</td>
  <td>15</td>
  <td>
    1.466667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>8</td>
  <td>12</td>
  <td>10</td>
  <td>
    1.066667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>14</td>
  <td>11</td>
  <td>5</td>
  <td>
    0.700000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>10</td>
  <td>13</td>
  <td>
    1.200000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>6</td>
  <td>11</td>
  <td>13</td>
  <td>
    1.233333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>8</td>
  <td>15</td>
  <td>
    1.266667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>11</td>
  <td>12</td>
  <td>
    1.166667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>8</td>
  <td>8</td>
  <td>14</td>
  <td>
    1.200000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>2</td>
  <td>10</td>
  <td>18</td>
  <td>
    1.533333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>6</td>
  <td>19</td>
  <td>5</td>
  <td>
    0.966667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>14</td>
  <td>14</td>
  <td>2</td>
  <td>
    0.600000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>14</td>
  <td>15</td>
  <td>1</td>
  <td>
    0.566667
    </td>
  </tr>

<tr><td><a href="#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>9</td>
  <td>12</td>
  <td>9</td>
  <td>
    1.000000
    </td>
  </tr>

<tr><td><a href="#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>8</td>
  <td>12</td>
  <td>10</td>
  <td>
    1.066667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>15</td>
  <td>11</td>
  <td>4</td>
  <td>
    0.633333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>8</td>
  <td>9</td>
  <td>13</td>
  <td>
    1.166667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>11</td>
  <td>13</td>
  <td>6</td>
  <td>
    0.833333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>5</td>
  <td>14</td>
  <td>11</td>
  <td>
    1.200000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>4</td>
  <td>15</td>
  <td>11</td>
  <td>
    1.233333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>17</td>
  <td>4</td>
  <td>9</td>
  <td>
    0.733333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>15</td>
  <td>8</td>
  <td>7</td>
  <td>
    0.733333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>11</td>
  <td>8</td>
  <td>11</td>
  <td>
    1.000000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>13</td>
  <td>5</td>
  <td>12</td>
  <td>
    0.966667
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>19</td>
  <td>6</td>
  <td>5</td>
  <td>
    0.533333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>8</td>
  <td>11</td>
  <td>11</td>
  <td>
    1.100000
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>6</td>
  <td>8</td>
  <td>15</td>
  <td>
    1.310345
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>6</td>
  <td>13</td>
  <td>11</td>
  <td>
    1.166667
    </td>
  </tr>

<tr><td><a href="#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>13</td>
  <td>5</td>
  <td>12</td>
  <td>
    0.966667
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>8</td>
  <td>9</td>
  <td>12</td>
  <td>
    1.137931
    </td>
  </tr>

<tr><td><a href="#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>12</td>
  <td>15</td>
  <td>3</td>
  <td>
    0.700000
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>8</td>
  <td>14</td>
  <td>7</td>
  <td>
    0.965517
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>7</td>
  <td>17</td>
  <td>5</td>
  <td>
    0.931034
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>5</td>
  <td>20</td>
  <td>4</td>
  <td>
    0.965517
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>8</td>
  <td>17</td>
  <td>4</td>
  <td>
    0.862069
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>17</td>
  <td>10</td>
  <td>2</td>
  <td>
    0.482759
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>6</td>
  <td>17</td>
  <td>6</td>
  <td>
    1.000000
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>14</td>
  <td>10</td>
  <td>5</td>
  <td>
    0.689655
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>2</td>
  <td>13</td>
  <td>15</td>
  <td>
    1.433333
    </td>
  </tr>

<tr><td><a href="#test.standardized">test.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>3</td>
  <td>12</td>
  <td>15</td>
  <td>
    1.400000
    </td>
  </tr>

<tr><td><a href="#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>5</td>
  <td>19</td>
  <td>6</td>
  <td>
    1.033333
    </td>
  </tr>

<tr><td><a href="#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>4</td>
  <td>3</td>
  <td>23</td>
  <td>
    1.633333
    </td>
  </tr>

<tr><td><a href="#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>6</td>
  <td>9</td>
  <td>15</td>
  <td>
    1.300000
    </td>
  </tr>

<tr><td><a href="#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>3</td>
  <td>9</td>
  <td>18</td>
  <td>
    1.500000
    </td>
  </tr>

<tr><td><a href="#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>6</td>
  <td>15</td>
  <td>9</td>
  <td>
    1.100000
    </td>
  </tr>

<tr><td><a href="#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>12</td>
  <td>12</td>
  <td>6</td>
  <td>
    0.800000
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>10</td>
  <td>19</td>
  <td>
    1.600000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>5</td>
  <td>14</td>
  <td>11</td>
  <td>
    1.200000
    </td>
  </tr>

<tr><td><a href="#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>9</td>
  <td>13</td>
  <td>8</td>
  <td>
    0.966667
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>12</td>
  <td>17</td>
  <td>
    1.533333
    </td>
  </tr>

<tr><td><a href="#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>5</td>
  <td>16</td>
  <td>9</td>
  <td>
    1.133333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>9</td>
  <td>14</td>
  <td>
    1.233333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>9</td>
  <td>14</td>
  <td>
    1.233333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>17</td>
  <td>8</td>
  <td>5</td>
  <td>
    0.600000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>10</td>
  <td>13</td>
  <td>7</td>
  <td>
    0.900000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>10</td>
  <td>15</td>
  <td>5</td>
  <td>
    0.833333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>2</td>
  <td>11</td>
  <td>17</td>
  <td>
    1.500000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>5</td>
  <td>11</td>
  <td>14</td>
  <td>
    1.300000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>10</td>
  <td>10</td>
  <td>10</td>
  <td>
    1.000000
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>13</td>
  <td>9</td>
  <td>8</td>
  <td>
    0.833333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>14</td>
  <td>9</td>
  <td>7</td>
  <td>
    0.766667
    </td>
  </tr>

<tr><td><a href="#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>13</td>
  <td>12</td>
  <td>5</td>
  <td>
    0.733333
    </td>
  </tr>

<tr><td><a href="#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>6</td>
  <td>11</td>
  <td>13</td>
  <td>
    1.233333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>11</td>
  <td>13</td>
  <td>6</td>
  <td>
    0.833333
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>4</td>
  <td>7</td>
  <td>19</td>
  <td>
    1.500000
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>4</td>
  <td>14</td>
  <td>11</td>
  <td>
    1.241379
    </td>
  </tr>

<tr><td><a href="#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>0</td>
  <td>7</td>
  <td>14</td>
  <td>9</td>
  <td>
    1.066667
    </td>
  </tr>

<tr><td><a href="#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>1</td>
  <td>4</td>
  <td>11</td>
  <td>14</td>
  <td>
    1.344828
    </td>
  </tr>

<tr><td><a href="#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>12</td>
  <td>14</td>
  <td>4</td>
  <td>
    0.733333
    </td>
  </tr>

</table>

<h2>Detailed Descriptions</h2>

<h1><a name="dev.reason.knowl">dev.reason.knowl</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Reason explicitly <br/>
<i>I want to</i> Annotate my program anywhere in the code with my current understanding of its
structure or execution <p/>
<i>Must Have:</i> 20,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 0
<p/>
<p>This general use case expresses the desire to place information about
a program's expected execution state in many different places throughout
the program - possibly including "upon function entry", "whenever this
line of code is executed", "at all times when a class of this type is not
actively executing a member function", or others.</p>
<br/>
<h1><a name="dev.reason.confidence">dev.reason.confidence</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Reason explicitly <br/>
<i>I want to</i> 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') <p/>
<i>Must Have:</i> 10,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 10
<p/>
<p>This high level use case expresses the need to attach information to contract
conditions that is beyond the statement of the condition itself, and instead
has user-provided metadata about both the confidence in the condition and the
desired behavior of the program in relation to that condition.</p>
<br/>
<h1><a name="dev.reason.importance">dev.reason.importance</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Reason explicitly <br/>
<i>I want to</i> Express a spectrum of importance of my annotations, from "critical" (eg. bring
the system down) to "minor" (eg. lead to a slower fallback) <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 15
<p/>
<p>This high level use case expresses the desire to have metadata on contract
conditions associated with what downsides violations might have, perhaps
indicating that while a certain condition is expected to be met, the library
does guarantee that the downsides will not be catastrophic.</p>
<br/>
<h1><a name="dev.reason.cost">dev.reason.cost</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Reason explicitly <br/>
<i>I want to</i> Express a spectrum of expected cost at compile or runtime of my annotations,
from "unrunnable" to "expensive" to "cheap" <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 7
<p/>
<p>This use case expresses the desire to have metadata about contract conditions
that capture at least 3 (if not more) granularities of "cost" to be used as
input in some way to other decisions about what the contracts might do or how
they might be interpreted.</p>
<br/>
<h1><a name="dev.reason.behavior">dev.reason.behavior</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Reason about executions <br/>
<i>I want to</i> Have annotations affect the execution of my program in accordance with my
expectations <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 7
<p/>
<p>The desire to have behaviors (such as generating runtime checks or
optimizations) and the expected behavior explicitly defined by the standard in
order to help users reason about what a program will do/has done when a
contract is violated. Note that having this in the standard allows for
leveraging expectations of behavior across all compliant platforms.</p>
<br/>
<h1><a name="dev.reason.sideeffects">dev.reason.sideeffects</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Reason about executions <br/>
<i>I want to</i> Ensure annotations do not substantially change the meaning of my program
whether enabled or disabled <p/>
<i>Must Have:</i> 19,
<i>Nice to Have:</i> 8,
<i>Not Important:</i> 3
<p/>
<p>This high-level use case expresses a desire that any execution effective
transformations an annotation might apply be "reasonable", ie. not surprising
or counter intuitive (such as time-travel optimizations).</p>
<p>There is a tension between allowing side effects in contract conditions and
disallowing them completely.  In general, writing code with absolutely no side
effects is very hard, and there are pitfalls if the language is actively
hostile to accidental side effects.  On the other hand, conditions with side
effects are also not elidable by the compiler, since the act of checking them
is observable.</p>
<ul>
<li>N4810 contracts made any side effect undefined behavior.</li>
<li>P1670 suggested allowing side effects but also, when contracts are runtime
checked, allowing elision of the predicate (along with its side effect) if the
predicate result can be determined.</li>
</ul>
<br/>
<h1><a name="dev.reason.behaviorcontrol">dev.reason.behaviorcontrol</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Reason about executions <br/>
<i>I want to</i> Have the effect of annotations on executions be user controllable (ie. decide
whether "cheap" checks or "critical" terminates) <p/>
<i>Must Have:</i> 16,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 4
<p/>
<p>This encompasses some specific need to control, either when writing code or
when building code, what behavior (if any) is associated with a contract
condition.</p>
<br/>
<h1><a name="dev.adapt">dev.adapt</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Adapt and progress with my project <br/>
<i>I want to</i> Be able to easily change my confidence, importance, or other properties of my
annotations over time <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 17,
<i>Not Important:</i> 2
<p/>

<br/>
<h1><a name="dev.readable.syntax">dev.readable.syntax</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Have readable annotations <br/>
<i>I want to</i> Have annotations with a succinct and elegant syntax <p/>
<i>Must Have:</i> 17,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 0
<p/>

<br/>
<h1><a name="dev.readable.keywords">dev.readable.keywords</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Have readable annotations <br/>
<i>I want to</i> Have annotation keywords or names with intuitive, clear, and unambiguous
meanings <p/>
<i>Must Have:</i> 19,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 0
<p/>
<p>Any keywords chosen for use within the feature should be easily distinguishable
(to avoid name churn such as expects/ensures to pre/post) and be very
clearly matched to what they will do within the language (unlike, for example,
axiom).</p>
<br/>
<h1><a name="dev.readable.priority">dev.readable.priority</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Have readable annotations <br/>
<i>I want to</i> Have my contract specification to be visually primary, and secondary
information (syntax, hints, roles, levels, etc.) to not be distracting <p/>
<i>Must Have:</i> 6,
<i>Nice to Have:</i> 17,
<i>Not Important:</i> 7
<p/>
<p>This use case indicates a preference to have any metadata about a contract be
visually very minimal or come after the predicate itself.</p>
<br/>
<h1><a name="dev.parsable">dev.parsable</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Interoperate with tools or persons <br/>
<i>I want to</i> A syntax that can both be parsed and can be reasoned about semantically <p/>
<i>Must Have:</i> 23,
<i>Nice to Have:</i> 6,
<i>Not Important:</i> 1
<p/>

<br/>
<h1><a name="dev.tooling">dev.tooling</a></h1>
<i>As a</i> Developer <br/>
<i>In order to</i> Interoperate with tools or persons <br/>
<i>I want to</i> Expose annotations to tools that might leverage them (eg. code linter, static
analyzer, semantic prover, compiler sanitizer, binary analyzer, code reviewer,
etc.) <p/>
<i>Must Have:</i> 20,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 1
<p/>

<br/>
<h1><a name="cppdev.syntax.familiar">cppdev.syntax.familiar</a></h1>
<i>As a</i> C++ Developer <br/>
<i>In order to</i> Get up to speed <br/>
<i>I want to</i> Have annotations use familiar syntax <p/>
<i>Must Have:</i> 3,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 12
<p/>

<br/>
<h1><a name="cppdev.syntax.cpp">cppdev.syntax.cpp</a></h1>
<i>As a</i> C++ Developer <br/>
<i>In order to</i> Get up to speed <br/>
<i>I want to</i> Have annotations use C++ syntax <p/>
<i>Must Have:</i> 10,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 8
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="cppdev.syntax.reuse">cppdev.syntax.reuse</a></h1>
<i>As a</i> C++ Developer <br/>
<i>In order to</i> Reuse code <br/>
<i>I want to</i> Have annotations use my custom types or functions <p/>
<i>Must Have:</i> 20,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 1
<p/>
<p>Rather than requiring special functions or types (or some completely new
thing), contract should be able to leverage any program logic related to their
statement that is already written/writable in C++.</p>
<br/>
<h1><a name="cppdev.location">cppdev.location</a></h1>
<i>As a</i> C++ Developer <br/>
<i>In order to</i> Have a single source of truth <br/>
<i>I want to</i> Use same source file for both code and annotations <p/>
<i>Must Have:</i> 25,
<i>Nice to Have:</i> 4,
<i>Not Important:</i> 1
<p/>
<p>This as a preference to needing to specify contracts in a completely separate
metadata file of some sort.</p>
<br/>
<h1><a name="cppdev.syntax.macros">cppdev.syntax.macros</a></h1>
<i>As a</i> C++ Developer <br/>
<i>In order to</i> Support modern features <br/>
<i>I want to</i> Minimize use of macros <p/>
<i>Must Have:</i> 7,
<i>Nice to Have:</i> 18,
<i>Not Important:</i> 5
<p/>
<p>The desire is to not require use of macros in order to satisfy the majority
of use cases.</p>
<br/>
<h1><a name="cppdev.modules">cppdev.modules</a></h1>
<i>As a</i> C++ Developer <br/>
<i>In order to</i> Support modern features <br/>
<i>I want to</i> Be interoperable with modules <p/>
<i>Must Have:</i> 24,
<i>Nice to Have:</i> 6,
<i>Not Important:</i> 0
<p/>
<p>All contract control features and behaviors should be interoperable in a
reasonable way with any partially or fully modularized C++ program.</p>
<br/>
<h1><a name="cppdev.coroutines">cppdev.coroutines</a></h1>
<i>As a</i> C++ Developer <br/>
<i>In order to</i> Support modern features <br/>
<i>I want to</i> Be interoperable with coroutines <p/>
<i>Must Have:</i> 16,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 3
<p/>
<p>Contracts on coroutines open up a number of new situations to consider because
there might be requirements on what the state of the program is whenever a
coroutine resumes execution, and there might be promises a coroutine makes
prior to each time it suspends.</p>
<br/>
<h1><a name="cppdev.concepts">cppdev.concepts</a></h1>
<i>As a</i> C++ Developer <br/>
<i>In order to</i> Support modern features <br/>
<i>I want to</i> Be interoperable with concepts <p/>
<i>Must Have:</i> 18,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 3
<p/>

<br/>
<h1><a name="cppdev.existing.std">cppdev.existing.std</a></h1>
<i>As a</i> C++ Developer <br/>
<i>In order to</i> Use the standard library in-contract <br/>
<i>I want to</i> Codify existing exposition-only standard library requirements <p/>
<i>Must Have:</i> 7,
<i>Nice to Have:</i> 18,
<i>Not Important:</i> 5
<p/>
<p>In some shape or form, anything documented in the contracts of the standard
library's functions (preconditions, postconditions, other behaviors) is a
candidate for something that should be codifiable as a contract condition.</p>
<br/>
<h1><a name="cppdev.debugger">cppdev.debugger</a></h1>
<i>As a</i> C++ Developer <br/>
<i>In order to</i> Use Debugger <br/>
<i>I want to</i> Have runtime able to launch a debugger from an annotation if necessary <p/>
<i>Must Have:</i> 8,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 10
<p/>
<p>When handling a contract violation, the ability to trigger a debugger when
possible is currently not standardized but should be available.</p>
<br/>
<h1><a name="cppdev.build.legacy">cppdev.build.legacy</a></h1>
<i>As a</i> C++ Developer <br/>
<i>In order to</i> Use existing build modes <br/>
<i>I want to</i> Have annotations affect executions depending on my existing build modes (eg.
Debug or Release modes in VS) <p/>
<i>Must Have:</i> 8,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 9
<p/>
<p>Note that "debug" and "release" are not standardized things, but nothing
specified in the standard should preclude those from having some impact on
what behaviors contracts take on in those two modes. It should be possible for
a vendor to map contract modes to their existing native modes.</p>
<br/>
<h1><a name="cdev.contracts">cdev.contracts</a></h1>
<i>As a</i> C Developer <br/>
<i>In order to</i> Write contracts on my functions <br/>
<i>I want to</i> Specify contracts in a way standardizable as part of the C language <p/>
<i>Must Have:</i> 2,
<i>Nice to Have:</i> 6,
<i>Not Important:</i> 21
, <i>No Answer:</i> 1
<p/>
<p>Important considerations for C are related to any contracts that can go on a
normal C function.  C does have attributes, but it also explicitly calls out
that a conforming implementation can ignore all attributes, as opposed to C++
which has made that a commonly held assumption but has not actually put wording
in the standard to that effect.</p>
<br/>
<h1><a name="cdev.identifiers">cdev.identifiers</a></h1>
<i>As a</i> C Developer <br/>
<i>In order to</i> Write contracts on my functions <br/>
<i>I want to</i> Use contracts with macro-safe keywords that are reserved C names (i.e., _Pre,
_Post, _Assert, etc.) <p/>
<i>Must Have:</i> 1,
<i>Nice to Have:</i> 6,
<i>Not Important:</i> 22
, <i>No Answer:</i> 1
<p/>
<p>Adding new identifiers with meaning in C is generally not acceptable for
standardization, so compatible contracts would either need to use no contracts
or support alternate reserved words for use with contracts.</p>
<br/>
<h1><a name="cdev.violationhandler">cdev.violationhandler</a></h1>
<i>As a</i> C Developer <br/>
<i>In order to</i> Write contracts on my functions <br/>
<i>I want to</i> Have a common violation handler for both violated C and C++ contracts <p/>
<i>Must Have:</i> 2,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 16
, <i>No Answer:</i> 1
<p/>
<p>Importantly, satisfying this requirement would mean making the the argument
to a violation handler meaningful in both C and C++, or requiring platform
vendors to shim between the two (in the case of a C violation handler receiving
a violation from C++ code).</p>
<br/>
<h1><a name="cdev.ignorable">cdev.ignorable</a></h1>
<i>As a</i> C Developer <br/>
<i>In order to</i> Write contracts on my functions <br/>
<i>I want to</i> Make all contract semantics optional (so as not to change WG14-N2385 6.7.11 p2) <p/>
<i>Must Have:</i> 3,
<i>Nice to Have:</i> 3,
<i>Not Important:</i> 23
, <i>No Answer:</i> 1
<p/>
<p>Assuming contracts continue to be rendered as attributes, C standardization
would require they be semantically optional.</p>
<p>Note that, just as with C++, the ':' in the previous contract syntax does not
match the grammar for attributes in either language, so by a strict reading of
the standards there is no obligation to be ignorable.  ('[[a:b]]' is not a
valid attribute and should be diagnosed as invalid on any current C or C++
compiler).   Many have expressed the view that this opinion is pedantic and
that the spirit of the law is that anything between [[]]s should be ignorable.</p>
<p>Additionally, it is currently a conforming extension to throw away all tokens
between a pair of [[]]s, and there exist numerous compilers that take advantage
of that fact which would be broken by requiring behavior of any constructs that
look like an attribute.</p>
<br/>
<h1><a name="ccppdev.interop">ccppdev.interop</a></h1>
<i>As a</i> Mixed C/C++ Developer <br/>
<i>In order to</i> Maintain mixed code base <br/>
<i>I want to</i> Not lose contracts when crossing languages <p/>
<i>Must Have:</i> 3,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 12
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="cdev.cppinterop">cdev.cppinterop</a></h1>
<i>As a</i> Mixed C/C++ Developer <br/>
<i>In order to</i> Write contracts on my functions <br/>
<i>I want to</i> Expose my contracts to C++ developers through 'extern "C"' declarations of my
functions <p/>
<i>Must Have:</i> 1,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 16
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="api.communicate.inputsoutputs">api.communicate.inputsoutputs</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Communicate my interface to users <br/>
<i>I want to</i> Document the expected inputs and expected outputs on my interface <p/>
<i>Must Have:</i> 22,
<i>Nice to Have:</i> 5,
<i>Not Important:</i> 3
<p/>

<br/>
<h1><a name="api.establish.check">api.establish.check</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Establish a contract <br/>
<i>I want to</i> Have validation inform me which output values are unexpected or invalid <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 2
<p/>

<br/>
<h1><a name="api.establish.validate_invariants">api.establish.validate_invariants</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Establish a contract <br/>
<i>I want to</i> Have validation inform me which class invariants are violated <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 2
<p/>
<p>Class invariants have historically been considered of general use, but the
performance impact of checking them can be surprisingly huge.  Previously
these have been left out of proposals for C++ to be added in at a later
date.</p>
<br/>
<h1><a name="api.establish.values">api.establish.values</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Establish a contract <br/>
<i>I want to</i> Have validation inform user which input values are unexpected or invalid <p/>
<i>Must Have:</i> 18,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 1
<p/>
<p>This establishes the basic requirement on preconditions in terms of input values.</p>
<p>The more detail available to users about how a contract condition has been
violated the more useful they become.  This means each specific condition
is benefited by being separate (eg. 'x != 0' and 'y != 0' as distinct
conditions instead of requiring that users use 'x != 0 &amp;&amp; y != 0').</p>
<p>In addition to that, anything that might be able to capture those values
and expose them to violation handlers for logging would again help benefit
problem diagnosis.</p>
<br/>
<h1><a name="api.establish.preconditions">api.establish.preconditions</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Establish a contract <br/>
<i>I want to</i> Have contracts specify their pre-conditions as logical predicates <p/>
<i>Must Have:</i> 25,
<i>Nice to Have:</i> 3,
<i>Not Important:</i> 2
<p/>
<p>This establishes the basic requirement to use predicates to evaluate input values.</p>
<br/>
<h1><a name="api.establish.invariants">api.establish.invariants</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Establish a contract <br/>
<i>I want to</i> Have contracts specify their class invariants as logical predicates <p/>
<i>Must Have:</i> 12,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 5
<p/>
<p>This establishes the basic requirement for invariants in terms of predicates on class members.</p>
<br/>
<h1><a name="api.establish.postconditions">api.establish.postconditions</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Establish a contract <br/>
<i>I want to</i> Have contracts specify their post-conditions as logical predicates <p/>
<i>Must Have:</i> 20,
<i>Nice to Have:</i> 5,
<i>Not Important:</i> 5
<p/>
<p>This establishes the basic requirement to use predicates to evaluate return values.</p>
<br/>
<h1><a name="api.express.values">api.express.values</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Express predicates <br/>
<i>I want to</i> Make reference to either the values of my inputs, or other in-scope identifiers <p/>
<i>Must Have:</i> 26,
<i>Nice to Have:</i> 2,
<i>Not Important:</i> 2
<p/>
<p>This establishes the basic requirement to reference in-scope variables in order capture values and compute predicates.</p>
<br/>
<h1><a name="api.establish.changedvalues">api.establish.changedvalues</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Establish a contract <br/>
<i>I want to</i> Make reference to the before and after values of in-out variables (ie. passed
by pointer or reference) in post-conditions <p/>
<i>Must Have:</i> 12,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 7
<p/>
<p>Postconditions often need to state things about how values of output parameters
have changed, or how the values of other global state might have changed
as a result of a function call.  The ability to store copies of state from
before the function call and reference that in a postcondition predicate will
enable a wider variety of conditions to be formulatable.</p>
<p>Ada has this functionality builtin by providing ways to reference explicitly
the original value of a function parameter. C++ makes this more complicated
with the need to consider the handling of move-only or generally non-copyable
types.  More importantly, such copying should absolutely not happen if a
contract is not being evaluated at runtime.</p>
<br/>
<h1><a name="api.establish.changedmembers">api.establish.changedmembers</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Establish a contract <br/>
<i>I want to</i> 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 <p/>
<i>Must Have:</i> 9,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 7
<p/>
<p>Capturing the pre-function state of member variables might also be needed
to state the contracts on many member functions.</p>
<br/>
<h1><a name="api.establish.changedstate">api.establish.changedstate</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Establish a contract <br/>
<i>I want to</i> Make reference to the before and after values of global state (eg., <i>global
&gt;= old(global) + 1</i>) in post-conditions <p/>
<i>Must Have:</i> 3,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 13
<p/>
<p>Capturing arbitrary global state for use in a postcondition might prove useful.</p>
<p>This extends to the state of arbitrary other expressions and how that might change
due to the invocation of a function.  Consider this example of what might
be a postcondition of a typical <code>sleep</code> function:</p>
<p><code>old(now()) &lt;= now() + sleep_time</code></p>
<br/>
<h1><a name="api.extend.exceptionsafety">api.extend.exceptionsafety</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Extend contractual aspects <br/>
<i>I want to</i> Annotate operations as being exception safe <p/>
<i>Must Have:</i> 0,
<i>Nice to Have:</i> 17,
<i>Not Important:</i> 13
<p/>
<p>Exception safety guarantees are often part of the English language contract of
a function, and being able to state that (in a way that tools might be able
to then pick up on and verify) would be useful.</p>
<br/>
<h1><a name="api.extend.threadsafety">api.extend.threadsafety</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Extend contractual aspects <br/>
<i>I want to</i> Annotate operations as being thread safe <p/>
<i>Must Have:</i> 0,
<i>Nice to Have:</i> 17,
<i>Not Important:</i> 13
<p/>
<p>The proper use of a type in a multithreaded environment can benefit greatly
from being documented in a way that can then be checked and verified.</p>
<br/>
<h1><a name="api.extend.atomicity">api.extend.atomicity</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Extend contractual aspects <br/>
<i>I want to</i> Annotate operations as being atomic (ie. all or no changes become visible) <p/>
<i>Must Have:</i> 0,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 15
<p/>
<p>Establishing more details about what might happen on failure, such as what
external state might be changed in a remote database, is another useful
condition to state.</p>
<br/>
<h1><a name="api.extend.realtime">api.extend.realtime</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Extend contractual aspects <br/>
<i>I want to</i> Annotate operations as real-time (ie. guaranteed to complete within a time
frame) <p/>
<i>Must Have:</i> 1,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 20
<p/>

<br/>
<h1><a name="api.extend.determinism">api.extend.determinism</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Extend contractual aspects <br/>
<i>I want to</i> Annotate operations as being deterministic (ie. same outputs for same inputs) <p/>
<i>Must Have:</i> 6,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 11
<p/>

<br/>
<h1><a name="api.extend.purity">api.extend.purity</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Extend contractual aspects <br/>
<i>I want to</i> Annotate operations as functionally pure (ie. no side effects) <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 10
<p/>

<br/>
<h1><a name="api.extend.sideeffects">api.extend.sideeffects</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Extend contractual aspects <br/>
<i>I want to</i> Annotate operations as having global side effects (ie. write to singleton,
file, network, or database) <p/>
<i>Must Have:</i> 0,
<i>Nice to Have:</i> 17,
<i>Not Important:</i> 13
<p/>

<br/>
<h1><a name="api.extend.complexity">api.extend.complexity</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Extend contractual aspects <br/>
<i>I want to</i> Annotate algorithmic complexity <p/>
<i>Must Have:</i> 0,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 19
<p/>

<br/>
<h1><a name="api.express.runnability">api.express.runnability</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Express unrunnable contracts <br/>
<i>I want to</i> Be able to use a predicate that is not evaluated at runtime, because it might
be unsafe to run or have stateful side effects <p/>
<i>Must Have:</i> 10,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 6
<p/>
<p>Numerous predicates that might be useful to state also might change the
state of a program in a paradoxical way if checked.  The common example
(originally put forward in P0380) is validating available items on an input
iterator.  Other important examples include checks that might require accessing
special hardware, or doing extensive computations that would invalidate the
results just by taking the time to do them.</p>
<p>These predicates are still useful for those reading the code, still might
benefit from being validated against postconditions of other functions, and
might provide some identifiable code improvements when analyzed by the compiler
without actually executing them at runtime.</p>
<br/>
<h1><a name="api.express.undefined">api.express.undefined</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Express unrunnable contracts <br/>
<i>I want to</i> Be able to use a predicate that doesn't have a definition, because it hasn't
been written yet, or is infeasible to run <p/>
<i>Must Have:</i> 10,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 8
<p/>
<p>Often during development it helps to write contracts first, and that might
even predate having enough of an implementation to fully define the conditions.
Having them in code ensures that the placeholder API to check them is
maintained.  Some functions may never be implementable due to time constraints,
while others will eventually be filled in as time allows.</p>
<br/>
<h1><a name="api.express.uncheckable">api.express.uncheckable</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Express uncheckable contracts <br/>
<i>I want to</i> Be able to use a predicate that is not evaluated, because it is simply a
semantic placeholder for a tool <p/>
<i>Must Have:</i> 10,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 8
<p/>
<p>Some predicates might even have no meaning within the language itself, but
benefit other tools by being placed into the same contract framework as other
predicates, with meaning to those external tools.</p>
<br/>
<h1><a name="api.express.unimplementable">api.express.unimplementable</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Express uncheckable contracts <br/>
<i>I want to</i> Be able to use a predicate that cannot have a complete definition, because it
is inexpressible in the language <p/>
<i>Must Have:</i> 10,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 11
<p/>
<p>Many external static analysis tools, and even compilers, can check that
some state is being handled properly which cannot be properly validated within
the language itself.  Consider functions such as "is_deletable" or
"is_reachable".</p>
<br/>
<h1><a name="api.establish.responsibility">api.establish.responsibility</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Establish responsibility boundaries <br/>
<i>I want to</i> Inform users which errors are the responsibility of the caller, and which are
the callee <p/>
<i>Must Have:</i> 15,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 4
<p/>
<p>One common realization with having checked contracts in the language is that 
they will then identify bugs that exist in programs.  Identifying the source
of those bugs swiftly is important, and for any contract that is dependent on
a function being called properly that responsibility does not usually lie with
the line of code where the contract is written, but with the place where
the function has been called.</p>
<br/>
<h1><a name="api.resp.preassert">api.resp.preassert</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Establish responsibility boundaries <br/>
<i>I want to</i> 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 <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 12
<p/>
<p>Some function preconditions can be expressed as c++ expressions, but are
runtime-expensive.  However, if expressed inside function body as assertions
after some function logic has already been executed,  the check whether the
function has everything that is required is cheap. If I use an assertion like
this,  I want to annotate this assertion as being "precondition-like". The
semantics would be that if it fails,  it is reported as "caller's bug" rather
than callee's bug, and if the build is configured  to runtime-check only
preconditions, such assertion should also be runtime-checked.</p>
<p>As an example, consider a binary search that wishes to check that the input
list is sorted.  There is an expensive check (O(n)) that can be done to verify
that the whole list is sorted on each call, but this would negate the
performance benefits of doing a binary search to begin with.  Another option
is to check just that the elements adjacent to those that are visited are in
properly sorted order.  This will provide some chance of identify unsorted
inputs without making performance unusable, but is also most cleanly done
during the execution of the search algorithm.  Unlike a normal in-body
assertion, a violation identified by this kind of check should be reported to
the caller, as it is a failure on the calling code's part to provide a
properly sorted input list.</p>
<br/>
<h1><a name="api.contract.interface">api.contract.interface</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Have contract as part of my interface <br/>
<i>I want to</i> Declare contract when I declare the function <p/>
<i>Must Have:</i> 21,
<i>Nice to Have:</i> 6,
<i>Not Important:</i> 3
<p/>
<p>Putting contracts on the first function declaration makes them easily visible
to anyone looking at a header file for understanding an API.</p>
<br/>
<h1><a name="api.contract.private">api.contract.private</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Keep my user interfaces clean and narrow <br/>
<i>I want to</i> Be able to access private implementation details of the class so I don't have
to widen public interface to declare predicates <p/>
<i>Must Have:</i> 13,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 5
<p/>
<p>Often, an interface might be very narrow - consider the interface on an
iterator, which generally just has a few operators and no other functions -
yet there  might be ways to check parts of a narrow contract that depend on
internal state.  Exposing this state so that it can be checked publicly would
require widening the API interface, which is counter to the desire to keep
the use of a type as simple as possible.</p>
<p>On a similar note, sometimes the internal state only approximates the actual
contract, and while better than no checking there is a desire to not expose
that data publicly so that there is no assumption that the data represents
the complete set of requirements on calling code.</p>
<br/>
<h1><a name="api.contract.redeclaration">api.contract.redeclaration</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Keep my public interfaces clean and concise <br/>
<i>I want to</i> 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). <p/>
<i>Must Have:</i> 7,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 12
<p/>
<p>Many development methodologies revolve around making readable, well-documented
header files to provide a way to understand API usage. Some contracts might
be simple and readable, but others might involve complex conditions that
distract from readability, and match very simple to read and understand prose
contracts in the documentation.</p>
<p>The benefits (checkability, analysis, etc.) of having the encoded contracts
should not come at the cost of making the primary visible public interface
(the header file) more unreadable.</p>
<br/>
<h1><a name="api.contract.errorhandling">api.contract.errorhandling</a></h1>
<i>As a</i> API Developer <br/>
<i>In order to</i> Move contract violation out of error handling <br/>
<i>I want to</i> Replace uses of error handling to express contract violation (eg.
<i>operator[](size_t n) noexcept [[pre: n &lt; size()]]</i> instead of
throwing) <p/>
<i>Must Have:</i> 12,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 7
<p/>
<p>Historically, rather than providing functions with narrow contracts, software
might have been written to report misuse through exceptions.  Contracts should
provide a better alternative than giving all functions a fully wide contract.</p>
<br/>
<h1><a name="cppapi.invariants">cppapi.invariants</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Write classes <br/>
<i>I want to</i> Declare class invariants that all of my public functions need to maintain <p/>
<i>Must Have:</i> 12,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 4
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="cppapi.class.preconditions">cppapi.class.preconditions</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Maintain a class hierarchy <br/>
<i>I want to</i> Ensure overriding methods have same or wider preconditions (see: Liskov
substitution principle) <p/>
<i>Must Have:</i> 6,
<i>Nice to Have:</i> 20,
<i>Not Important:</i> 4
<p/>

<br/>
<h1><a name="cppapi.class.postconditions">cppapi.class.postconditions</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Maintain a class hierarchy <br/>
<i>I want to</i> Ensure overriding functions meet their base class postconditions when their
base class preconditions are met (see: Liskov substitution principle) <p/>
<i>Must Have:</i> 8,
<i>Nice to Have:</i> 20,
<i>Not Important:</i> 2
<p/>

<br/>
<h1><a name="cppapi.class.variability">cppapi.class.variability</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Maintain a class hierarchy. <br/>
<i>I want to</i> Allow overriding functions to have narrower preconditions/wider postconditions
if I want to <p/>
<i>Must Have:</i> 3,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 13
<p/>
<p>P4810 did not allow any variation in contract conditions through overrides of
a virtual function, though this could be roughly accomplished with assertions
in function bodies instead.</p>
<p>In general, the pre and postconditions of the interface you call through should
be checked to be sure you're meeting the requirements you want to meet.
Similarly, the concrete type's conditions should be checked to be sure it is
behaving properly.  Doing both checks if they are different might be an
acceptable solution to allow flexibility without any increase in risk, at the
possible cost of some performance in checked builds.</p>
<br/>
<h1><a name="api.class.publicinterface">api.class.publicinterface</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Express public class invariants <br/>
<i>I want to</i> 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 <p/>
<i>Must Have:</i> 2,
<i>Nice to Have:</i> 19,
<i>Not Important:</i> 9
<p/>
<p>Requirements on an interface to a function should be impossible when entering
into a type's functions, but there might be a desire to distinguish that
so that checking is done differently when a type calls its own functions.</p>
<br/>
<h1><a name="api.class.publicinvariants">api.class.publicinvariants</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Express public class invariants <br/>
<i>I want to</i> Check invariants before and after every public method (when called from outside
the type, not when one member function calls another) <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 21,
<i>Not Important:</i> 5
<p/>
<p>General class invariants should be checked for validity before and after any
call to a public member function of a class.  Calls to friend functions need
to be considered as well, as they might benefit from invalidating/validating
invariants.  Similarly, invariants might be checked for all objects of the
type that are being touched whenever a public function is starting or
finishing.</p>
<br/>
<h1><a name="api.class.publiccalls">api.class.publiccalls</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Express public class invariants <br/>
<i>I want to</i> Check invariants before and after calling functions that are not part of this
type (including virtual calls) <p/>
<i>Must Have:</i> 2,
<i>Nice to Have:</i> 20,
<i>Not Important:</i> 8
<p/>
<p>Calling from a member function to a function of another type (or a possible
subtype) might require verifying that the object's invariants hold prior to
calling the function and that they still hold when the other function returns.</p>
<br/>
<h1><a name="api.class.baseinterface">api.class.baseinterface</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Express base class invariants <br/>
<i>I want to</i> 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 <p/>
<i>Must Have:</i> 1,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 14
<p/>
<p>Similar to the public API of a class, the protected API is exposed to
subclasses and invariants of that API should be checked whenever the boundary
might be crossed.</p>
<br/>
<h1><a name="api.class.baseinvariants">api.class.baseinvariants</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Express base class invariants <br/>
<i>I want to</i> Check invariants on entry and exit of every protected method (when called from
the derived type, not when one base member function calls another) <p/>
<i>Must Have:</i> 2,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 14
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="api.class.basecalls">api.class.basecalls</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Express base class invariants <br/>
<i>I want to</i> Check invariants before and after every call to a virtual function (when
calling to the derived type) <p/>
<i>Must Have:</i> 2,
<i>Nice to Have:</i> 18,
<i>Not Important:</i> 10
<p/>

<br/>
<h1><a name="api.class.privateinterface">api.class.privateinterface</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Express private class invariants <br/>
<i>I want to</i> 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 <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 12
<p/>

<br/>
<h1><a name="api.class.privateinvariants">api.class.privateinvariants</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Express private class invariants <br/>
<i>I want to</i> Check invariants on entry and exit of every public method (when called from
outside the type, not when one member function calls another) <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 17,
<i>Not Important:</i> 9
<p/>

<br/>
<h1><a name="api.class.privatecalls">api.class.privatecalls</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Express private class invariants <br/>
<i>I want to</i> Check invariants before and after calling functions that are not part of this
type (including virtual calls) <p/>
<i>Must Have:</i> 2,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 13
<p/>

<br/>
<h1><a name="api.class.testing">api.class.testing</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Test my classes <br/>
<i>I want to</i> 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 <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 10
<p/>

<br/>
<h1><a name="cppapi.contracts.async">cppapi.contracts.async</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Enforce contracts in async code <br/>
<i>I want to</i> Express contracts on callbacks such as std::function, function pointers, or
references to functions, lambdas, or function objects <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 21,
<i>Not Important:</i> 4
<p/>
<p>In general, any callback based solution exposes functions that will be called
that might benefit from having information about their contracts also
transmitted.</p>
<p>This might be implemented by incorporating contracts deeply into the type
system, or in a more limitted way by just facilitating library types like
a function with contracts.</p>
<br/>
<h1><a name="cppapi.contracts.exception">cppapi.contracts.exception</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Enforce contracts in exception safe code <br/>
<i>I want to</i> Express contracts on exceptional exit <p/>
<i>Must Have:</i> 6,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 11
<p/>
<p>Generally, postconditions have been assumed to hold when a function returns
normally.  Expressing conditions that will hold if a function returns through
an exception, or both, could also be useful.</p>
<br/>
<h1><a name="cppapi.variadic">cppapi.variadic</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Use contracts with variadic templates <br/>
<i>I want to</i> Allow predicate (fold) expansion <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 4
<p/>
<p>Fold expressions using &amp;&amp; might be useful for a predicate, but they then lose
any information about which particular argument might have violated the
condition.  Enabling more useful information to narrow that down would be
helpful.</p>
<br/>
<h1><a name="api.coroutines">api.coroutines</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Use coroutines <br/>
<i>I want to</i> Define and check pre and post conditions as I would a regular function <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 4
<p/>
<p>Like regular functions, pre and postconditions on coroutines should have
similar semantics.</p>
<br/>
<h1><a name="api.coroutines.invariants">api.coroutines.invariants</a></h1>
<i>As a</i> C++ API Developer <br/>
<i>In order to</i> Use coroutines <br/>
<i>I want to</i> Define and check invariants over all entry and exit points from a coroutine (to
its awaiter or promise) <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 19,
<i>Not Important:</i> 7
<p/>
<p>Similar to a class, the state of a coroutine, or what it expects of the state
of the world as it suspends and resumes, might be stated as expected invariants
that could be checked whenever entering and exiting.</p>
<br/>
<h1><a name="int.conform.violation">int.conform.violation</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Conform to a contract <br/>
<i>I want to</i> Be informed any time an interface's contract is violated <p/>
<i>Must Have:</i> 16,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 2
<p/>

<br/>
<h1><a name="int.conform.postconditions">int.conform.postconditions</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Conform to a contract <br/>
<i>I want to</i> Verify results from a call are expected output values <p/>
<i>Must Have:</i> 17,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 4
<p/>

<br/>
<h1><a name="int.build.headeronly">int.build.headeronly</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Build multiple libraries <br/>
<i>I want to</i> Use contract-enabled header-only libraries <p/>
<i>Must Have:</i> 24,
<i>Nice to Have:</i> 6,
<i>Not Important:</i> 0
<p/>

<br/>
<h1><a name="int.build.binaries">int.build.binaries</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Build multiple libraries <br/>
<i>I want to</i> Use contract-enabled binary libraries <p/>
<i>Must Have:</i> 21,
<i>Nice to Have:</i> 7,
<i>Not Important:</i> 1
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="int.build.binarycounts">int.build.binarycounts</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Build multiple libraries <br/>
<i>I want to</i> Only be required to manage a small, common set of build/link configurations <p/>
<i>Must Have:</i> 9,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 6
<p/>

<br/>
<h1><a name="int.build.control">int.build.control</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Debug multiple libraries <br/>
<i>I want to</i> Enable checks only within a selected library <p/>
<i>Must Have:</i> 15,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 1
<p/>

<br/>
<h1><a name="int.build.control2">int.build.control2</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Debug multiple libraries <br/>
<i>I want to</i> Enable checks on multiple libraries simultaneously <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 2
<p/>

<br/>
<h1><a name="int.debug.callsites">int.debug.callsites</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Debug multiple call sites <br/>
<i>I want to</i> Enable checks only on selected call sites <p/>
<i>Must Have:</i> 7,
<i>Nice to Have:</i> 18,
<i>Not Important:</i> 5
<p/>
<p>Often it is helpful to limit what gets enabled to functions called from
some subset of a program, and the rest of the program might not perform
acceptably enough to test if hose same functions are always checked.</p>
<br/>
<h1><a name="int.violations.information">int.violations.information</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Correct failed checks <br/>
<i>I want to</i> Be informed what check failed, when, where, and how <p/>
<i>Must Have:</i> 20,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 1
<p/>

<br/>
<h1><a name="int.violations.transmit">int.violations.transmit</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Correct failed checks <br/>
<i>I want to</i> Transmit check failure information in environment-specific ways (logs, email,
special hardware traps, popup windows, blazing sirens, etc). <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 5
<p/>

<br/>
<h1><a name="int.violations.custom">int.violations.custom</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Correct failed checks <br/>
<i>I want to</i> Install custom violation handler where I can inject custom logic to trap errors <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 7
<p/>

<br/>
<h1><a name="int.violations.common">int.violations.common</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Unify violation handling <br/>
<i>I want to</i> Be able to override how library violations are handled in the combined software
to point into my handling code <p/>
<i>Must Have:</i> 15,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 6
<p/>

<br/>
<h1><a name="int.violations.override">int.violations.override</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Be independent of build environment <br/>
<i>I want to</i> Be able to define and override violation handler via source code <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 14
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="int.build.minimize">int.build.minimize</a></h1>
<i>As a</i> Integration Developer <br/>
<i>In order to</i> Minimize checking overhead <br/>
<i>I want to</i> Disable library postconditions, asserts, and invariants, without disabling
library preconditions (assuming the library is tested and stable and my code is
not) <p/>
<i>Must Have:</i> 8,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 8
<p/>

<br/>
<h1><a name="int.control.build">int.control.build</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Ensure the combined software is correct <br/>
<i>I want to</i> Turn checks on at build time <p/>
<i>Must Have:</i> 21,
<i>Nice to Have:</i> 6,
<i>Not Important:</i> 3
<p/>

<br/>
<h1><a name="int.control.runtime">int.control.runtime</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Ensure the combined software is correct <br/>
<i>I want to</i> Turn checks on at run time <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 14
<p/>

<br/>
<h1><a name="int.conrol.subsets.build">int.conrol.subsets.build</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Ensure the combined software is correct <br/>
<i>I want to</i> Turn on any subset of individual (call site) checks on at build time <p/>
<i>Must Have:</i> 9,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 8
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="int.control.subsets.runtime">int.control.subsets.runtime</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Ensure the combined software is correct <br/>
<i>I want to</i> Turn on any subset of individual (call site) checks on at run time <p/>
<i>Must Have:</i> 3,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 15
<p/>

<br/>
<h1><a name="int.consistency">int.consistency</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Ensure the combined software is correct <br/>
<i>I want to</i> Verify all annotations are globally consistent when integrated <p/>
<i>Must Have:</i> 3,
<i>Nice to Have:</i> 20,
<i>Not Important:</i> 6
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="int.control.subsets">int.control.subsets</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Ensure individual features are correct <br/>
<i>I want to</i> Have a way to audit (named or semantic) subsets of checks for various
deployments <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 16,
<i>Not Important:</i> 9
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="int.build.common">int.build.common</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Manage binary delivery <br/>
<i>I want to</i> Be able to use the same executable regardless of contract enforcement mode <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 16
<p/>

<br/>
<h1><a name="int.testing.control">int.testing.control</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Define "Code Under Test" <br/>
<i>I want to</i> Selectively enable checking for a set of functions which could name either an
individual function or an overload set <p/>
<i>Must Have:</i> 3,
<i>Nice to Have:</i> 16,
<i>Not Important:</i> 11
<p/>

<br/>
<h1><a name="int.testing.controltypes">int.testing.controltypes</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Define "Code Under Test" <br/>
<i>I want to</i> Selectively enable checking for a set of types and all their members <p/>
<i>Must Have:</i> 3,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 12
<p/>

<br/>
<h1><a name="int.testing.transitivity">int.testing.transitivity</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Define "Code Under Test" <br/>
<i>I want to</i> Selectively enable checking for a set of types and all their transitively
nested types and members <p/>
<i>Must Have:</i> 3,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 13
<p/>

<br/>
<h1><a name="int.testing.modules">int.testing.modules</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Define "Code Under Test" <br/>
<i>I want to</i> Selectively enable checking for a translation unit or module and all (non
transitive) types and functions within <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 19,
<i>Not Important:</i> 6
<p/>

<br/>
<h1><a name="int.build.unchecked">int.build.unchecked</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Test final deliverable <br/>
<i>I want to</i> Turn off build time checking to remove checking overhead <p/>
<i>Must Have:</i> 15,
<i>Nice to Have:</i> 6,
<i>Not Important:</i> 9
<p/>

<br/>
<h1><a name="int.runtime.unchecked">int.runtime.unchecked</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Test final deliverable <br/>
<i>I want to</i> Turn off run time checking to remove checking overhead <p/>
<i>Must Have:</i> 22,
<i>Nice to Have:</i> 5,
<i>Not Important:</i> 3
<p/>

<br/>
<h1><a name="int.build.optimize">int.build.optimize</a></h1>
<i>As a</i> Integrated Software Provider <br/>
<i>In order to</i> Test final deliverable <br/>
<i>I want to</i> Turn on run time optimization to leverage annotation assumptions <p/>
<i>Must Have:</i> 12,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 6
<p/>

<br/>
<h1><a name="cpplib.headeronly">cpplib.headeronly</a></h1>
<i>As a</i> C++ Library Developer <br/>
<i>In order to</i> Use templates <br/>
<i>I want to</i> Be able to ship header only library <p/>
<i>Must Have:</i> 25,
<i>Nice to Have:</i> 4,
<i>Not Important:</i> 1
<p/>

<br/>
<h1><a name="cpplib.insulation">cpplib.insulation</a></h1>
<i>As a</i> C++ Library Developer <br/>
<i>In order to</i> Control the tradeoff between need for client recompilation and contract condition visibility <br/>
<i>I want to</i> 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. <p/>
<i>Must Have:</i> 6,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 11
<p/>
<p>Contract conditions on only the first declaration (as proposed by P4810) mean
that the condition clutters the readable interface and changes in a contract
condition force client recompilation.  Contract conditions not in the header
file are not going to be visible to tools that are attempting to limit what
they consume to a single translation unit.  Combined, these result in a desire
to sometimes put the contracts with the implementing definition (in a .cpp
file) and sometimes put them in a redeclaration in a header file (where one
might also put inline function definitions).</p>
<p>For free functions this would just require relaxing the requirements on where
contracts are.  For member functions, allowing member function redeclaration
would be needed to put the contracts in a less obtrusive place that is still
visible outside of the defining TU.  See P1320 for more discussion of this.</p>
<br/>
<h1><a name="lib.maintenance.noconfig">lib.maintenance.noconfig</a></h1>
<i>As a</i> Library Provider <br/>
<i>In order to</i> Simplify maintenance <br/>
<i>I want to</i> Not require extra build steps to be documented <p/>
<i>Must Have:</i> 6,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 14
<p/>

<br/>
<h1><a name="lib.maintenance.nowhining">lib.maintenance.nowhining</a></h1>
<i>As a</i> Library Provider <br/>
<i>In order to</i> Simplify maintenance <br/>
<i>I want to</i> Not have users complain about my product due to modifications of annotations
resulting from their build configuration <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 17
<p/>

<br/>
<h1><a name="lib.integration.noconfig">lib.integration.noconfig</a></h1>
<i>As a</i> Library Provider <br/>
<i>In order to</i> Support successful integration <br/>
<i>I want to</i> Not require extra build steps to be learned or performed <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 13
<p/>

<br/>
<h1><a name="lib.integration.nowhining">lib.integration.nowhining</a></h1>
<i>As a</i> Library Provider <br/>
<i>In order to</i> Support successful integration <br/>
<i>I want to</i> Not have my users accidentally modify my careful annotations <p/>
<i>Must Have:</i> 7,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 12
<p/>

<br/>
<h1><a name="arch.nomacros">arch.nomacros</a></h1>
<i>As a</i> Technical Architect <br/>
<i>In order to</i> Maintain quality of code base <br/>
<i>I want to</i> 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) <p/>
<i>Must Have:</i> 10,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 7
<p/>

<br/>
<h1><a name="arch.complete">arch.complete</a></h1>
<i>As a</i> Technical Architect <br/>
<i>In order to</i> Have a consistent and holistic contracts facility <br/>
<i>I want to</i> 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) <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 3
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="hardware.performance">hardware.performance</a></h1>
<i>As a</i> Hardware Architect <br/>
<i>In order to</i> Improve system-level performance <br/>
<i>I want to</i> Be able to design new hardware + optimizations, carefully dovetailed into one
another, that depend on statically-unprovable facts being annotated in the code <p/>
<i>Must Have:</i> 10,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 8
, <i>No Answer:</i> 2
<p/>

<br/>
<h1><a name="sdev.bestpractices">sdev.bestpractices</a></h1>
<i>As a</i> Senior Developer <br/>
<i>In order to</i> Set an example <br/>
<i>I want to</i> Demonstrate best practice in defensive programming <p/>
<i>Must Have:</i> 18,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 3
<p/>

<br/>
<h1><a name="sdev.quality">sdev.quality</a></h1>
<i>As a</i> Senior Developer <br/>
<i>In order to</i> Enforce code quality <br/>
<i>I want to</i> Discourage reliance on observable out-of-contract behavior by causing check
failure to hard stop program or build <p/>
<i>Must Have:</i> 16,
<i>Nice to Have:</i> 6,
<i>Not Important:</i> 8
<p/>

<br/>
<h1><a name="sdev.maturity">sdev.maturity</a></h1>
<i>As a</i> Senior Developer <br/>
<i>In order to</i> Enforce mature, finalized contracts <br/>
<i>I want to</i> Disable continuation on violation of stable and correct individual contracts <p/>
<i>Must Have:</i> 19,
<i>Nice to Have:</i> 7,
<i>Not Important:</i> 4
<p/>

<br/>
<h1><a name="sdev.control">sdev.control</a></h1>
<i>As a</i> Senior Developer <br/>
<i>In order to</i> Enforce mature, finalized contracts <br/>
<i>I want to</i> Disable remapping of semantics on stable and correct individual contracts <p/>
<i>Must Have:</i> 9,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 9
<p/>

<br/>
<h1><a name="jdev.understand.contracts">jdev.understand.contracts</a></h1>
<i>As a</i> Junior Developer <br/>
<i>In order to</i> Understand the API <br/>
<i>I want to</i> A uniform, fluent description of expected input values, expected output values,
side effects, and all logical pre and post conditions <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 1
<p/>

<br/>
<h1><a name="jdev.understand.violations">jdev.understand.violations</a></h1>
<i>As a</i> Junior Developer <br/>
<i>In order to</i> Understand the API <br/>
<i>I want to</i> Be informed when my usage is out of contract <p/>
<i>Must Have:</i> 21,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 0
<p/>

<br/>
<h1><a name="jdev.understand.buildfailures">jdev.understand.buildfailures</a></h1>
<i>As a</i> Junior Developer <br/>
<i>In order to</i> Understand the program <br/>
<i>I want to</i> Know why my software is not building <p/>
<i>Must Have:</i> 21,
<i>Nice to Have:</i> 6,
<i>Not Important:</i> 3
<p/>

<br/>
<h1><a name="jdev.understand.aborting">jdev.understand.aborting</a></h1>
<i>As a</i> Junior Developer <br/>
<i>In order to</i> Understand the program <br/>
<i>I want to</i> Know why my software is aborting <p/>
<i>Must Have:</i> 20,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 1
<p/>

<br/>
<h1><a name="jdev.understand.omniscience">jdev.understand.omniscience</a></h1>
<i>As a</i> Junior Developer <br/>
<i>In order to</i> Understand the program <br/>
<i>I want to</i> Know why my software is out of contract <p/>
<i>Must Have:</i> 18,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 1
<p/>

<br/>
<h1><a name="jdev.understand.buildviolation">jdev.understand.buildviolation</a></h1>
<i>As a</i> Junior Developer <br/>
<i>In order to</i> Understand the program <br/>
<i>I want to</i> Know that my program or build was halted due to contract violation <p/>
<i>Must Have:</i> 23,
<i>Nice to Have:</i> 7,
<i>Not Important:</i> 0
<p/>

<br/>
<h1><a name="jdev.understand.all">jdev.understand.all</a></h1>
<i>As a</i> Junior Developer <br/>
<i>In order to</i> Understand the facility <br/>
<i>I want to</i> Be able to build a program with contracts after reasonably short tutorial <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 4
<p/>

<br/>
<h1><a name="jdev.understand.keywords">jdev.understand.keywords</a></h1>
<i>As a</i> Junior Developer <br/>
<i>In order to</i> Understand the facility <br/>
<i>I want to</i> Have keywords with precise and unambiguous meanings <p/>
<i>Must Have:</i> 15,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 2
<p/>

<br/>
<h1><a name="jdev.bestpractices">jdev.bestpractices</a></h1>
<i>As a</i> Junior Developer <br/>
<i>In order to</i> Improve my code <br/>
<i>I want to</i> Learn about software best practices by example <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 4
<p/>

<br/>
<h1><a name="adev.fast">adev.fast</a></h1>
<i>As a</i> Agile Developer <br/>
<i>In order to</i> Iterate quickly <br/>
<i>I want to</i> Be able to write and modify contracts quickly without heavy boiler plate or up
front cost <p/>
<i>Must Have:</i> 15,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 1
<p/>

<br/>
<h1><a name="adev.evolve">adev.evolve</a></h1>
<i>As a</i> Agile Developer <br/>
<i>In order to</i> Safeguard evolving code <br/>
<i>I want to</i> Assert against conditions I am aware of but not finished handling fully <p/>
<i>Must Have:</i> 10,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 8
<p/>

<br/>
<h1><a name="bdev.confidentiality">bdev.confidentiality</a></h1>
<i>As a</i> Business Developer <br/>
<i>In order to</i> Maintain confidentiality <br/>
<i>I want to</i> 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 <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 14
<p/>

<br/>
<h1><a name="pdev.speed">pdev.speed</a></h1>
<i>As a</i> Performance Sensitive Developer <br/>
<i>In order to</i> Enable better performance <br/>
<i>I want to</i> 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 <p/>
<i>Must Have:</i> 13,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 7
<p/>

<br/>
<h1><a name="pdev.morespeed">pdev.morespeed</a></h1>
<i>As a</i> Performance Sensitive Developer <br/>
<i>In order to</i> Enable better performance <br/>
<i>I want to</i> 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 <p/>
<i>Must Have:</i> 13,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 6
<p/>

<br/>
<h1><a name="pdev.footgun">pdev.footgun</a></h1>
<i>As a</i> Performance Sensitive Developer <br/>
<i>In order to</i> Enable better performance <br/>
<i>I want to</i> Accept responsibility for a malformed program that might result from eventually
false information given by my annotations <p/>
<i>Must Have:</i> 15,
<i>Nice to Have:</i> 8,
<i>Not Important:</i> 7
<p/>

<br/>
<h1><a name="pdev.safety.isolation">pdev.safety.isolation</a></h1>
<i>As a</i> Performance Sensitive Developer <br/>
<i>In order to</i> Have safety critical paths <br/>
<i>I want to</i> Isolate safety checks from performance annotations <p/>
<i>Must Have:</i> 12,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 7
<p/>

<br/>
<h1><a name="pdev.safety.critical">pdev.safety.critical</a></h1>
<i>As a</i> Performance Sensitive Developer <br/>
<i>In order to</i> Have safety critical paths <br/>
<i>I want to</i> Retain checking even when optimizing with performance annotations <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 8,
<i>Not Important:</i> 8
<p/>

<br/>
<h1><a name="qdev.checkall">qdev.checkall</a></h1>
<i>As a</i> Quality Sensitive Developer <br/>
<i>In order to</i> Enable full checking <br/>
<i>I want to</i> Ensure all checks (pre, post, assert, invariant) are enabled <p/>
<i>Must Have:</i> 18,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 2
<p/>

<br/>
<h1><a name="qdev.correctness">qdev.correctness</a></h1>
<i>As a</i> Quality Sensitive Developer <br/>
<i>In order to</i> Validate correctness <br/>
<i>I want to</i> Signify the predicates that should be verified by an analysis tool <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 19,
<i>Not Important:</i> 6
<p/>

<br/>
<h1><a name="qdev.tooling">qdev.tooling</a></h1>
<i>As a</i> Quality Sensitive Developer <br/>
<i>In order to</i> Manage multiple tools <br/>
<i>I want to</i> Signify subset of individual annotations to be consumed by a specific kind of
verification tool <p/>
<i>Must Have:</i> 2,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 14
<p/>

<br/>
<h1><a name="qdev.tooling.control">qdev.tooling.control</a></h1>
<i>As a</i> Quality Sensitive Developer <br/>
<i>In order to</i> Manage multiple tools <br/>
<i>I want to</i> Signify subset of individual annotations to be consumed by a specific instance
of verification tool <p/>
<i>Must Have:</i> 1,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 14
<p/>

<br/>
<h1><a name="qdev.tooling.undefined">qdev.tooling.undefined</a></h1>
<i>As a</i> Quality Sensitive Developer <br/>
<i>In order to</i> Manage multiple tools <br/>
<i>I want to</i> Use predicates that may not be understood by all instances of verification <p/>
<i>Must Have:</i> 9,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 9
<p/>

<br/>
<h1><a name="qdev.tooling.undefinedkinds">qdev.tooling.undefinedkinds</a></h1>
<i>As a</i> Quality Sensitive Developer <br/>
<i>In order to</i> Manage multiple tools <br/>
<i>I want to</i> Use predicates that may not be understood by all kinds of verification <p/>
<i>Must Have:</i> 10,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 8
<p/>

<br/>
<h1><a name="qdev.tooling.behavior">qdev.tooling.behavior</a></h1>
<i>As a</i> Quality Sensitive Developer <br/>
<i>In order to</i> Manage multiple tools <br/>
<i>I want to</i> Integrate the results of that static checker into how my program behaves in
different ways: assume proven predicates, make unprovable predicates ill-
formed, etc. <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 15
<p/>

<br/>
<h1><a name="qdev.testing">qdev.testing</a></h1>
<i>As a</i> Quality Sensitive Developer <br/>
<i>In order to</i> Unit test predicates <br/>
<i>I want to</i> Override failure handler to trigger test failure instead of termination <p/>
<i>Must Have:</i> 13,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 8
<p/>

<br/>
<h1><a name="qdev.handler.testing">qdev.handler.testing</a></h1>
<i>As a</i> Quality Sensitive Developer <br/>
<i>In order to</i> Unit test violation handlers <br/>
<i>I want to</i> Have a way to run handler on all combinations of available build modes <p/>
<i>Must Have:</i> 6,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 11
<p/>

<br/>
<h1><a name="qdev.fuzz.testing">qdev.fuzz.testing</a></h1>
<i>As a</i> Quality Sensitive Developer <br/>
<i>In order to</i> Catch unexpected failure modes <br/>
<i>I want to</i> Log all predicate failure during fuzz testing <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 5
<p/>

<br/>
<h1><a name="crit.control">crit.control</a></h1>
<i>As a</i> Critical Software Developer <br/>
<i>In order to</i> Have a verifiable release system <br/>
<i>I want to</i> Be able to control the configuration of contracts from a central point <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 4
<p/>

<br/>
<h1><a name="crit.noundef">crit.noundef</a></h1>
<i>As a</i> Critical Software Developer <br/>
<i>In order to</i> Avoid undefined behavior <br/>
<i>I want to</i> Have contract violation at run-time always have well-defined behavior <p/>
<i>Must Have:</i> 9,
<i>Nice to Have:</i> 4,
<i>Not Important:</i> 17
<p/>

<br/>
<h1><a name="crit.recovery">crit.recovery</a></h1>
<i>As a</i> Critical Software Developer <br/>
<i>In order to</i> Not have a faulty program lead to catastrophic failure <br/>
<i>I want to</i> Have access to a recovery path after contract violation <p/>
<i>Must Have:</i> 7,
<i>Nice to Have:</i> 8,
<i>Not Important:</i> 15
<p/>

<br/>
<h1><a name="crit.redundancy">crit.redundancy</a></h1>
<i>As a</i> Critical Software Developer <br/>
<i>In order to</i> Not have a faulty program lead to catastrophic failure <br/>
<i>I want to</i> Be able to express error handling that may be redundant with contract checking <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 8,
<i>Not Important:</i> 11
<p/>

<br/>
<h1><a name="crit.interaction">crit.interaction</a></h1>
<i>As a</i> Critical Software Developer <br/>
<i>In order to</i> Not have a faulty program lead to catastrophic failure <br/>
<i>I want to</i> Not have contract build or run modes possibly be able to change or disable
related error handling in any way <p/>
<i>Must Have:</i> 12,
<i>Nice to Have:</i> 5,
<i>Not Important:</i> 13
<p/>

<br/>
<h1><a name="crit.locality">crit.locality</a></h1>
<i>As a</i> Critical Software Developer <br/>
<i>In order to</i> Be assured a critical violation uses a critical recovery path <br/>
<i>I want to</i> Couple recovery path to a specific contract within the source <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 6,
<i>Not Important:</i> 19
<p/>

<br/>
<h1><a name="crit.testing">crit.testing</a></h1>
<i>As a</i> Critical Software Developer <br/>
<i>In order to</i> Meet code coverage requirements <br/>
<i>I want to</i> Be able to run both success and failure branches in my test environment <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 8
<p/>

<br/>
<h1><a name="crit.production.checking">crit.production.checking</a></h1>
<i>As a</i> Critical Software Developer <br/>
<i>In order to</i> Have redundant layering <br/>
<i>I want to</i> Be able to continue to run checks in a production environment (even after
formal testing is complete) <p/>
<i>Must Have:</i> 15,
<i>Nice to Have:</i> 8,
<i>Not Important:</i> 6
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="crit.more.coverage">crit.more.coverage</a></h1>
<i>As a</i> Critical Software Developer <br/>
<i>In order to</i> Maximize coverage <br/>
<i>I want to</i> Be able to run checks in a production environment that are considered "cheap"
compared to the expected cost of entering an invalid state <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 6
<p/>

<br/>
<h1><a name="crit.noassume">crit.noassume</a></h1>
<i>As a</i> Critical Software Developer <br/>
<i>In order to</i> Avoid unexpected or undefined behavior <br/>
<i>I want to</i> 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) <p/>
<i>Must Have:</i> 12,
<i>Nice to Have:</i> 5,
<i>Not Important:</i> 13
<p/>

<br/>
<h1><a name="sec.noattacks">sec.noattacks</a></h1>
<i>As a</i> Security Sensitive Developer <br/>
<i>In order to</i> Limit attack vectors <br/>
<i>I want to</i> Be unable to insert code paths (eg. violation handlers) at run time (eg. build
time only) <p/>
<i>Must Have:</i> 12,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 8
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="sec.certify">sec.certify</a></h1>
<i>As a</i> Security Sensitive Developer <br/>
<i>In order to</i> Deliver a certified product <br/>
<i>I want to</i> Have build tool only link to a preapproved violation handler <p/>
<i>Must Have:</i> 3,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 12
<p/>

<br/>
<h1><a name="analysis.runtime">analysis.runtime</a></h1>
<i>As a</i> User of Analysis Tools <br/>
<i>In order to</i> Improve runtime correctness <br/>
<i>I want to</i> Have runtime checks generated by the tool <p/>
<i>Must Have:</i> 7,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 8
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="analysis.optimization">analysis.optimization</a></h1>
<i>As a</i> User of Analysis Tools <br/>
<i>In order to</i> Improve runtime performance <br/>
<i>I want to</i> Have runtime optimizations generated by the tool <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 17,
<i>Not Important:</i> 7
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="analysis.symbolic">analysis.symbolic</a></h1>
<i>As a</i> User of Analysis Tools <br/>
<i>In order to</i> Allow symbolic analysis <br/>
<i>I want to</i> Have symbolic proofs for soundness and consistency performed before compile
time <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 20,
<i>Not Important:</i> 5
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="analysis.compiletime">analysis.compiletime</a></h1>
<i>As a</i> User of Analysis Tools <br/>
<i>In order to</i> Allow code analysis <br/>
<i>I want to</i> Have code source, AST, or instruction inspection during compile time <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 17,
<i>Not Important:</i> 8
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="analysis.binaries">analysis.binaries</a></h1>
<i>As a</i> User of Analysis Tools <br/>
<i>In order to</i> Allow binary analysis <br/>
<i>I want to</i> Have binary inspection after compile time <p/>
<i>Must Have:</i> 2,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 17
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="analysis.information">analysis.information</a></h1>
<i>As a</i> User of Analysis Tools <br/>
<i>In order to</i> Improve the quality of analysis <br/>
<i>I want to</i> 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>) <p/>
<i>Must Have:</i> 6,
<i>Nice to Have:</i> 17,
<i>Not Important:</i> 6
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="analysis.legacy">analysis.legacy</a></h1>
<i>As a</i> Provider of Analysis Tools <br/>
<i>In order to</i> Extend my existing engine <br/>
<i>I want to</i> Be able to map pre-existing contract features in tools to a standardized
language syntax <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 14
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="teach.bestpractices">teach.bestpractices</a></h1>
<i>As a</i> Teacher <br/>
<i>In order to</i> Demonstrate best practice <br/>
<i>I want to</i> Be able to express defensive programming, programming by contract, and test
driven development to introductory students <p/>
<i>Must Have:</i> 15,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 2
<p/>

<br/>
<h1><a name="test.standardized">test.standardized</a></h1>
<i>As a</i> Teacher <br/>
<i>In order to</i> Demonstrate best practice <br/>
<i>I want to</i> Not rely on custom libraries or proprietary extensions <p/>
<i>Must Have:</i> 15,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 3
<p/>

<br/>
<h1><a name="teach.lifecycle">teach.lifecycle</a></h1>
<i>As a</i> Teacher <br/>
<i>In order to</i> Demonstrate best practice <br/>
<i>I want to</i> Demonstrate mock lifecycle by switching simple compiler flags to control which
checks are enabled <p/>
<i>Must Have:</i> 6,
<i>Nice to Have:</i> 19,
<i>Not Important:</i> 5
<p/>

<br/>
<h1><a name="teach.portable">teach.portable</a></h1>
<i>As a</i> Teacher <br/>
<i>In order to</i> Manage many students <br/>
<i>I want to</i> Have examples compilable by a standard compiler on any system <p/>
<i>Must Have:</i> 23,
<i>Nice to Have:</i> 3,
<i>Not Important:</i> 4
<p/>

<br/>
<h1><a name="teach.dumbstudents">teach.dumbstudents</a></h1>
<i>As a</i> Teacher <br/>
<i>In order to</i> Manage many students <br/>
<i>I want to</i> Have examples that are easy to build without digression into build systems <p/>
<i>Must Have:</i> 15,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 6
<p/>

<br/>
<h1><a name="teach.teachable">teach.teachable</a></h1>
<i>As a</i> Teacher <br/>
<i>In order to</i> Build layers of understanding <br/>
<i>I want to</i> Have simple explanation of assertions and their use to support simple
programming tasks, including debugging erroneous programs. <p/>
<i>Must Have:</i> 18,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 3
<p/>

<br/>
<h1><a name="teach.layering">teach.layering</a></h1>
<i>As a</i> Teacher <br/>
<i>In order to</i> Build layers of understanding <br/>
<i>I want to</i> Support the ability for advanced uses of contracts to be distributed across
many different courses in a C++-focused computer science curriculum. <p/>
<i>Must Have:</i> 9,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 6
<p/>

<br/>
<h1><a name="compiler.benice">compiler.benice</a></h1>
<i>As a</i> Compiler Developer <br/>
<i>In order to</i> Deliver best experience to my customers <br/>
<i>I want to</i> Maximize implementation freedom by limiting what is strictly required by the
standard <p/>
<i>Must Have:</i> 6,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 12
<p/>

<br/>
<h1><a name="compiler.best">compiler.best</a></h1>
<i>As a</i> Compiler Developer <br/>
<i>In order to</i> Deliver the best implementation <br/>
<i>I want to</i> Have a clear and simple specification that meets clear need <p/>
<i>Must Have:</i> 19,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 1
<p/>

<br/>
<h1><a name="large.complex">large.complex</a></h1>
<i>As a</i> Large Codebase Developer <br/>
<i>In order to</i> Debug complex issues <br/>
<i>I want to</i> 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 <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 5
<p/>

<br/>
<h1><a name="large.critical">large.critical</a></h1>
<i>As a</i> Large Codebase Developer <br/>
<i>In order to</i> Enable/Disable checking on critical/hot paths <br/>
<i>I want to</i> Control whether checks are run based on where they are being called from <p/>
<i>Must Have:</i> 8,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 9
<p/>

<br/>
<h1><a name="large.modernize">large.modernize</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Modernize my code base <br/>
<i>I want to</i> Introduce standardized contracts to replace my macro-based contracts <p/>
<i>Must Have:</i> 17,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 1
<p/>

<br/>
<h1><a name="large.stillmacros">large.stillmacros</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Modernize my code base <br/>
<i>I want to</i> Have my existing macro-based facilities interoperate smoothly with standardized
contracts so I can do the migration gradually <p/>
<i>Must Have:</i> 9,
<i>Nice to Have:</i> 16,
<i>Not Important:</i> 5
<p/>

<br/>
<h1><a name="large.observation">large.observation</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Introduce new contracts into an existing system <br/>
<i>I want to</i> Have failed individual checks from existing code optionally warn instead of
hard stop <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 7
<p/>

<br/>
<h1><a name="large.introduction">large.introduction</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Introduce new contracts into an existing system <br/>
<i>I want to</i> Have failed checks from a new library optionally warn instead of hard stop <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 7
<p/>

<br/>
<h1><a name="large.separability">large.separability</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Introduce new parameters or invariants into a contracts based system <br/>
<i>I want to</i> Be able to include distinct clauses for each parameter or invariant with their
own individual failure or build controls <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 8,
<i>Not Important:</i> 17
<p/>

<br/>
<h1><a name="large.newenvironment">large.newenvironment</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Introduce new elements into a contracts based system <br/>
<i>I want to</i> Have failed checks caused by a change in environment optionally warn instead of
hard stop <p/>
<i>Must Have:</i> 7,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 10
<p/>

<br/>
<h1><a name="large.newcompiler">large.newcompiler</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Introduce new elements into a contracts based system <br/>
<i>I want to</i> Have failed checks caused by a change in compiler optionally warn instead of
hard stop <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 15,
<i>Not Important:</i> 10
<p/>

<br/>
<h1><a name="large.nogoingback">large.nogoingback</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Prevent regressions <br/>
<i>I want to</i> Have trusted contracts fail fast and hard stop <p/>
<i>Must Have:</i> 17,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 2
<p/>

<br/>
<h1><a name="large.scalability">large.scalability</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Scale violation handling <br/>
<i>I want to</i> Be able to log violations in my organization specific format <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 5
<p/>

<br/>
<h1><a name="large.simulation.disable">large.simulation.disable</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Allow simulation or post-mortem testing of known failure modes <br/>
<i>I want to</i> Optionally disable checking on a subset of individual annotations <p/>
<i>Must Have:</i> 10,
<i>Nice to Have:</i> 10,
<i>Not Important:</i> 10
<p/>

<br/>
<h1><a name="large.simulation.enable">large.simulation.enable</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Allow simulation or post-mortem testing of known failure modes <br/>
<i>I want to</i> Optionally allow checking of a subset of individual annotations to fail and
access its recovery path <p/>
<i>Must Have:</i> 8,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 13
<p/>

<br/>
<h1><a name="large.simulation.ignore">large.simulation.ignore</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Allow simulation or post-mortem testing of known failure modes <br/>
<i>I want to</i> Optionally allow checking of a subset of individual annotations to fail and
continue failing <p/>
<i>Must Have:</i> 7,
<i>Nice to Have:</i> 9,
<i>Not Important:</i> 14
<p/>

<br/>
<h1><a name="large.perfcontrol.build">large.perfcontrol.build</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Manage performance cost <br/>
<i>I want to</i> Constrain the set of built time checks according to their performance overhead <p/>
<i>Must Have:</i> 5,
<i>Nice to Have:</i> 12,
<i>Not Important:</i> 13
<p/>

<br/>
<h1><a name="large.perfcontrol.runtime">large.perfcontrol.runtime</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Manage performance cost <br/>
<i>I want to</i> Constrain the set of runtime checks according to their performance overhead <p/>
<i>Must Have:</i> 13,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 6
<p/>

<br/>
<h1><a name="large.narrowing">large.narrowing</a></h1>
<i>As a</i> Large Codebase Owner <br/>
<i>In order to</i> Tune contract width in complex system <br/>
<i>I want to</i> Be able to narrow individual contract so it fails in testing not in production <p/>
<i>Must Have:</i> 6,
<i>Nice to Have:</i> 13,
<i>Not Important:</i> 11
<p/>

<br/>
<h1><a name="embedded.nochecking">embedded.nochecking</a></h1>
<i>As a</i> Small Machine Developer <br/>
<i>In order to</i> Minimize executable footprint <br/>
<i>I want to</i> Remove all checking and diagnostic (eg. source location) overhead entirely from
the final binary <p/>
<i>Must Have:</i> 19,
<i>Nice to Have:</i> 7,
<i>Not Important:</i> 4
<p/>

<br/>
<h1><a name="embedded.nologging">embedded.nologging</a></h1>
<i>As a</i> Small Machine Developer <br/>
<i>In order to</i> Minimize executable footprint <br/>
<i>I want to</i> Remove all logging and diagnostic (but not checking) overhead from the final
binary <p/>
<i>Must Have:</i> 11,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 4
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="embedded.minimize">embedded.minimize</a></h1>
<i>As a</i> Small Machine Developer <br/>
<i>In order to</i> Minimize executable footprint <br/>
<i>I want to</i> Remove all but the most important diagnostic overhead from the final binary <p/>
<i>Must Have:</i> 9,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 7
<p/>

<br/>
<h1><a name="wg21.everythingelse">wg21.everythingelse</a></h1>
<i>As a</i> Language Developer <br/>
<i>In order to</i> Interoperate with Contracts <br/>
<i>I want to</i> Have a clear way to understand how contracts will interact with the standard
library <p/>
<i>Must Have:</i> 14,
<i>Nice to Have:</i> 11,
<i>Not Important:</i> 4
, <i>No Answer:</i> 1
<p/>

<br/>
<h1><a name="wg21.otherfeatures">wg21.otherfeatures</a></h1>
<i>As a</i> Language Developer <br/>
<i>In order to</i> Extend contracts beyond pre/post conditions on functions <br/>
<i>I want to</i> 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. <p/>
<i>Must Have:</i> 4,
<i>Nice to Have:</i> 14,
<i>Not Important:</i> 12
<p/>

<br/>

<br/>

<h2>Acknowledgements</h2>
<p>Thanks to everyone who has participated in the SG21 reflector, telecon, and
our first meeting in Belfast.   Herb Sutter contributed greatly by taking the
vast raw data that made up our use cases and painfully populated the online
survey that everyone participated in.  Thanks also to all 30 respondents who
took a significant portion of their personal time to read, understand, and
express their opinions on the 195 use cases presented here.</p>

</body>
</html>

