<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">

<style type="text/css">
pre {font-family: "Consolas", "Lucida Console", monospace; margin-left:20pt; }
code {font-family: "Consolas", "Lucida Console", monospace; }
pre > i   { font-family: "Consolas", "Lucida Console", monospace;  font-style:italic; }
code > i  { font-family: "Consolas", "Lucida Console", monospace;  font-style:italic; }
pre > em  { font-family: "Consolas", "Lucida Console", monospace;  font-style:italic; }
code > em { font-family: "Consolas", "Lucida Console", monospace;  font-style:italic; }
body { color: #000000; background-color: #FFFFFF; }
del { text-decoration: line-through; color: #8B0040; }
ins { text-decoration: underline; color: #005100; }

p.example   { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }

code.extract { background-color: #F5F6A2; }
pre.extract  { margin-left: 2em; background-color: #F5F6A2;  border: 1px solid #E1E28E; }

p.function    { }
.attribute    { margin-left: 2em; }
.attribute dt { float: left; font-style: italic;  padding-right: 1ex; }
.attribute dd { margin-left: 0em; }

blockquote.std    { color: #000000; background-color: #F1F1F1;  border: 1px solid #D1D1D1;  padding-left: 0.5em; padding-right: 0.5em; }
blockquote.stddel { text-decoration: line-through;  color: #000000; background-color: #FFEBFF;  border: 1px solid #ECD7EC;  padding-left: 0.5empadding-right: 0.5em; ; }
blockquote.stdins { text-decoration: underline;  color: #000000; background-color: #C8FFC8;  border: 1px solid #B3EBB3; padding: 0.5em; }
table.header { border: 0px; border-spacing: 0;  margin-left: 0px; font-style: normal; }
table { border: 1px solid black; border-spacing: 0px;  margin-left: auto; margin-right: auto; }
th { text-align: left; vertical-align: top;  padding-left: 0.4em; border: none;  padding-right: 0.4em; border: none; }
td { text-align: left;  padding-left: 0.4em; border: none;  padding-right: 0.4em; border: none; }
</style>

<title>P2182R0: Contract Support: Defining the Minimum Viable Feature Set</title>

</head>
<body>

<table class="header"><tbody>
  <tr>
    <th>Document number:&nbsp;&nbsp;</th><th> </th><td>P2182R0</td>
  </tr>
  <tr>
    <th>Date:&nbsp;&nbsp;</th><th> </th><td>2020-06-15</td>
  </tr>
  <tr>
    <th>Audience:&nbsp;&nbsp;</th><th> </th><td>SG21</td>
  </tr>
  <tr>
    <th>Reply-to:&nbsp;&nbsp;</th><th> </th><td><address>Andrzej Krzemie&#324;ski &lt;akrzemi1 at gmail dot com&gt;</address>
	<address>Ryan McDougall</address><address>Joshua Berne</address></td>
  </tr>
</tbody></table>



<h1>Contract Support: Defining the Minimum Viable Feature Set</h1>


    <p>We observe that "C++20 contracts" consisted of two parts. 
	One part was clear, well understood, widely agreed upon, and useful 
	to various groups of C++ users. The other part rose a lot of controversies
	for various reasons and ultimately led to the removal of the entire feature.
	</p>
	
	<p>In paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2114r0.html"
    >[P2114r0]</a> we have listed a subset of use cases we believe represent useful improvements
  to the language, offer a incalculable positive value for most users, and reflect the
  uncontroversial part of "C++20 contracts". In this paper we provide the rationale for our
  choice. We wish to show that our selection:</p>
	
	<ul>
	<li>is big enough to be called a Minimum Viable Product (MVP) and get support of the majority of C++ programmers</li>
	<li>does not require controversial design, or features not already implemented in other languages</li>
	<li>does not prevent the addition of any of the remaining features of "C++20 contracts", or other discussed alternatives, in subsequent stages</li>
	</ul>
	
	

<h2><a name="analysis">Analysis</a></h2>


	<p>In this document we use the term <em>C++20 Contracts</em> to refer to contract support
	facilities in C++ Standard draft just before the removal &mdash;
    
	  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4820.pdf">[N4820]</a>
      (which is effectively equivalent to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html">[P0542R5]</a>)
      &mdash;
      
          as well as pieces of the associated proposals seen by EWG that had support in polling, such as: </p>
          <ul>
            <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1290r3.pdf">[P1290R3]</a></li>
            <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1344r1.md">[P1344R1]</a></li>
            <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1429r3.pdf">[P1429R3]</a></li>
            <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1607r1.pdf">[P1607R1]</a></li>
            <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1711r0.pdf">[P1711R0]</a></li>
          </ul>
	
    <p><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2076r0.html">[P2076r0]</a> 
    lists the points the disagreements about the previous incarnation of contracts design:</p>

    <ul>
    <li>Continuation Mode</li>
    <li>Build Levels</li>
    <li>Global Toggles (also known as: external remapping controls)</li>
    <li>Literal Semantics (also known as: in-source controls)</li>
    <li>Assumptions</li>
    </ul>

    <p>We claim that if we eliminated or reduced the use cases for the above features, the remainder
    would still be a valuable and usable feature that would offer a great help in enforcing program
    correctness. The value in preventing bugs and enforcing program correctness comes from being able to</p>
	
	<ol>
    <li>express preconditions, postconditions, and assertions as C++ predicates</li>
    <li>transform them into runtime-checks at an all-or-none granularity, leaving open the design of finer control to future work</li>
  </ol>
	
	<p>In the reminder of the paper we elaborate on the features of MVP and show how they are motivated
  by the use cases nominated in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2114r0.html"
    >[P2114r0]</a>. We also discuss how the support for the remaining use cases can be added atop of MVP
    in subsequent phases.</p>



<h3><a name="analysis.going_in">Features in MVP</a></h3>


<p>We selected the minimal use cases to allow the widest benefit for the most
general section of users, without resorting to known points of contention. We had
in mind a simple feature that consisted of the existing contract syntax,
a single build option to enable or disable checks, and a (conditionally) user-
definable violation handler that is invoked when checks are enabled and violated.</p>



<h4><a name="analysis.going_in.declarations">Contract declarations</a></h4>

    <p>The most important thing is the ability to express the predicates in function declarations 
	as compiler-checked C++ expressions. This is uncontroversial. This enables: </p>
    
    <ul>
    <li>compiler to report type-system errors from incorrectly spelled constraints</li>
    <li>generation of run-time code &mdash; such as contract checks, or unit tests</li>
    <li>annotation aware static analysis</li>
    </ul>
    
    <p>In fact, this feature alone would already satisfy many users.</p>
    
    <p>Use cases covered:</p>
    
    <ul>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#dev.reason.knowl"><code>dev.reason.knowl</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#dev.readable.syntax"><code>dev.readable.syntax</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#dev.readable.keywords"><code>dev.readable.keywords</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#dev.parsable"><code>dev.parsable</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#dev.tooling"><code>dev.tooling</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#cppdev.syntax.familiar"><code>cppdev.syntax.familiar</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#cppdev.syntax.cpp"><code>cppdev.syntax.cpp</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#cppdev.syntax.reuse"><code>cppdev.syntax.reuse</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#cppdev.location"><code>cppdev.location</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#api.communicate.inputsoutputs"><code>api.communicate.inputsoutputs</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#api.establish.preconditions"><code>api.establish.preconditions</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#api.establish.postconditions"><code>api.establish.postconditions</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#api.express.values"><code>api.express.values</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#api.contract.errorhandling"><code>api.contract.errorhandling</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#arch.nomacros"><code>arch.nomacros</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#arch.complete"><code>arch.complete</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#sdev.bestpractices"><code>sdev.bestpractices</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#jdev.understand.contracts"><code>jdev.understand.contracts</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#jdev.understand.keywords"><code>jdev.understand.keywords</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#adev.fast"><code>adev.fast</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#teach.bestpractices"><code>teach.bestpractices</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#teach.standardized"><code>teach.standardized</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#teach.portable"><code>teach.portable</code></a></li>
    </ul>
    
    
	
    
<h4><a name="analysis.going_in.on_off">Turning on and off all runtime checks</a></h4>

    <p>We believe it is essential that we meet two somewhat contradictory requirements:</p>
    
    <ol>
        <li>A guarantee that some action is taken whenever a contract is violated</li>
        <li>A guarantee that there is no runtime overhead for encoded contracts</li>
    </ol>

    <p>
      The former is a correctness requirement, and the latter is performance requirement 
    (after assurance &mdash; further discussion about assurance can be found in 
    <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1517r0.html#background">[P1517R0]</a>).
    </p>
    
    <p>This suggests that there needs to be at least some control over what
      contracts can do at build time.  For the MVP we suggest a single flag which
      turns checking "on" or "off", where:</p>

    <ul>
      <li>Off is simply syntax-checked</li>
      <li>On evaluates the predicate and invokes a violation handler when the predicate is false</li>
    </ul>

    <p>
      This is a subset of what
      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html">[P0542R5]</a>
      offered, and should come with similar caveats that that proposal had for
      build modes &mdash; where mixing modes is only conditionally supported.</p>

    <p>Finer-grained control and additional semantics to failed checks would be
      left to extensions and future proposals. </p>
    
    <p>Use cases covered:</p>
    
    <ul>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#dev.reason.sideeffects"><code>dev.reason.sideeffects</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#int.conform.postconditions"><code>int.conform.postconditions</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#int.control.build"><code>int.control.build</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#int.runtime.unchecked"><code>int.runtime.unchecked</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#qdev.checkall"><code>qdev.checkall</code></a></li>
    </ul>
    
    
<h4><a name="analysis.going_in.logging">Reporting contract violation</a></h4>


    <p>On platforms where it makes sense, each contract violation detected at run-time should 
    be reported to the users &mdash; including what failed and where in the source code.</p>
    
    <p>Use cases covered:</p>
    
    <ul>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#api.establish.check"><code>api.establish.check</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#api.establish.values"><code>api.establish.values</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#int.conform.violation"><code>int.conform.violation</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#int.violations.information"><code>int.violations.information</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#jdev.understand.violations"><code>jdev.understand.violations</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#jdev.understand.aborting"><code>jdev.understand.aborting</code></a></li>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#jdev.understand.buildviolation"><code>jdev.understand.buildviolation</code></a></li>
    </ul>
    
    
 <h4><a name="analysis.going_in.custom_handler">Customizing how failures are reported</a></h4>
 
 
 <p>The semantics and implementation of contract violation handling has significant
 impact on the extensibility and usability of the feature. It may be premature to
 codify within an MVP, as it may reduce the applicability of the feature
  to a significant portion of use cases. For the MVP, we think that as offered in
  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html">[P0542R5]</a>,
  implementations are not required to offer customizable violation handlers.</p>

<p>Note that in practice, it is expected that most implementations will allow
  users to define a custom violation handler. This will let users experiment with
  many variations before bringing them to the committee, and do so in a way
  that is portable across all compilers that do allow customizability.
  Compilers that do not allow user-defined violation handlers would instead
  document what their (default or other selectable) violation handler will do
  when invoked. </p>

<p>Other use cases related to contract semantics can be met or at least approximated
  with the choice of specific violation handlers, and we seek to avoid limiting
  that decision in this proposal.  For this reason we would not propose requiring
  that user defined violation handlers be <code>[[noreturn]]</code>, and we
  suggest no other behavior related to a violation other than the invocation of
  the violation handler</p>
    
	<p>Use cases covered (implementation defined):</p>
    
    <ul>
    <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#int.violations.common"><code>int.violations.common</code></a></li>
    </ul>
    

<h3><a name="analysis.stayng_out">Features not in MVP</a></h3>



<h4><a name="analysis.stayng_out.continuation">Continuation after failed run-time check</a></h4>
    

    <p>The use case that continuation mode was trying to address are <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#sdev.maturity"><code>sdev.maturity</code></a>
    and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#large.newcompiler"><code>large.newcompiler</code></a>. They can be introduced on top of MVP as annotations
    on individual contract declarations (as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1332r0.txt"
                                                            >[P1332R0]</a>), and additionally requiring more build modes.</p>

<p>In addition to that, by only specifying that a violation handler is invoked
  and not extending that to any other fixed functionality associated with a
  violation (such as always terminating) we allow for users to remain in
  control of this decision when choosing compilers that provide selectable
  violation handlers. </p>
    
    
    
<h4><a name="analysis.stayng_out.levels">Contract Levels</a></h4>

    <p>The use cases that contract levels, such as <code>default</code> and <code>audit</code>, tried to address
    are <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#crit.more.coverage"><code>crit.more.coverage</code></a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#dev.reason.cost"><code>dev.reason.cost</code></a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#crit.production.checking"><code>crit.production.checking</code></a>. The goal was to
    indicate "this predicate is more expensive to evaluate than the function it protects",
    but the design of this feature had flaws:
    </p>
	
	<ul>
	<li>Syntax cannot handle templates where the level may depend on template arguments.</li>
	<li>Two levels (or even three) cannot be enough.</li>
	<li>Levels is not enough to convey essential meta information.</li>
	<li>Syntax is not extensible.</li>
	<li>Syntax is uncomfortable.</li>
	</ul>
    
    <p>They can be introduced on top of MVP as annotations indicating how expensive a contract statement is relative to 
    the body of the function.</p>
    
   
  
<h4><a name="analysis.stayng_out.build_levels">Global Toggles (also known as: external remapping controls)</a></h4>


    <p>If there are no levels in contract declarations in the MVP, there is no need for having build
    levels either, other than on/off switch. They can be added later if needed.</p>
    
 

<h4><a name="analysis.stayng_out.literal_semantics">Literal Semantics (also known as: in-source controls)</a></h4> 


    <p>They were never in the draft, but were discussed widely, and had some EWG support in polling.
    There were concerns that they</p>
    <ol>
      <li>would encourage the use of macros</li>
      <li>were not basic/necessary building blocks</li>
    </ol>
    <p>However they can easily be added atop of MVP in future version by adding meta-information to contract declarations.</p>


 
<h4><a name="analysis.stayng_out.assumptions">Assumptions or injected facts</a></h4>
 
 
	<p>This was highly controversial. An extended analysis can be found in 
    <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2064r0.pdf">[P2064r0]</a>.
    Use cases covered: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#pdev.footgun"><code>pdev.footgun</code></a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#hardware.performance"><code>hardware.performance</code></a>.</p>
    
    <p><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#pdev.footgun"><code>pdev.footgun</code></a> can be handled by a separate feature, such as 
    <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1774r3.pdf">[P1774r3]</a>.
    Alternatively, it could be implemented atop of MVP by adding special meta-information to 
    individual contract declarations.</p>
    
    <p><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#hardware.performance"><code>hardware.performance</code></a> could be implemented atop of MVP by introducing a yet another
    build mode. Alternatively, users could achieve it with MVP by installing a custom
    violation handler with <code>__builtin_unreachable()</code>.</p>
	


<h4><a name="analysis.stayng_out.axioms">Indicating inexpressible predicates</a></h4>


    <p>This woud cover use cases <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#qdev.tooling.control"><code>qdev.tooling.control</code></a> and
    <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#api.express.unimplementable"><code>api.express.unimplementable</code></a>. Controversies arose because of mixng
    inexpressibility with levels, and taking word "axiom" to mean <code>__builtin_assume()</code>.</p>
    
    <p>Can be implemented atop of MVP either as meta-information on contract declarations, or
    by annotating functions as inexpressible as described in
    <a href="https://isocpp.org/files/papers/P2176R0.html">[P2176r0]</a>.</p>
    
 
 
<h2><a name="conclusion">Conclusion</a></h2>
 
 
	<p>While the proposed MVP is conservative, we believe that even the MVP may
    contain a number of unresolved small issues that will require time to polish. With EWG attention
    almost entirely consumed by controversial bits of C++20 contracts, the uncontroversial bits
    may not have been given sufficient consideration for attention. If we are to ship any
    contract programming support in C++23 time frame, we have to be sure that we have a small
    enough scope to be accommodated by the WG21 process.</p>

    <p>
    The biggest advantage of this MVP is that we provide a standard notation for expressing
    preconditions and postconditions. This notation will be consumed by many tools, which are not
    necessarily compilers. The positive effect on the community is not necessarily in what compilers
    can do with it, but also what other automated tools can get from it. This is far beyond the
    scope of the C++ Standard.</p>


<h2><a name="literature">References</a></h2>

<ul>

    <li>[P2114r0] &mdash; Joshua Berne, Ryan McDougall, Andrzej Krzemieński, 
    "Minimal Contract Use Cases" <br/>
    (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2114r0.html"
    >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2114r0.html</a>).    
    </li>
    
    <li>[P1995r0] &mdash; Joshua Berne, Timur Doumler, Andrzej Krzemieński, Ryan McDougall, Herb Sutter, 
    "Contracts &mdash; Use Cases" <br/>
    (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html"
    >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html</a>).    
    </li>
    
    <li>[P2185r0] &mdash; Caleb Sunstrum, 
    "Contracts Use Case Categorization" <br/>
    (<a href="https://isocpp.org/files/papers/P2185R0.html"
    >https://isocpp.org/files/papers/P2185R0.html</a>).    
    </li>
    
	<li>[N4820] &mdash; Richard smith, "Working Draft, Standard for Programming Language C++",<br/>
	<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4820.pdf"
	>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4820.pdf</a>).
	</li>
	
    <li>[P0542r5] &mdash; G. Dos Reis, J. D. Garcia, J. Lakos, A. Meredith, N. Myers, B. Stroustrup,
      "Support for contract based programming in C++" <br/>
      (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html"
      >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html</a>).
      </li>

    <li>[p2076r0] &mdash; Ville Voutilainen, "Previous disagreements on Contracts" <br/>
    (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2076r0.html"
    >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2076r0.html</a>).</li>
    
    <li>[P1774r3] &mdash; Timur Doumler, "Portable assumptions" <br/>
    <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1774r3.pdf"
    >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1774r3.pdf</a>).</li>
    
    <li>[P1332r0] &mdash; Joshua Berne, Nathan Burgers, Hyman Rosen, John Lakos,
    "Contract Checking in C++: A (long-term) Road Map" <br/>
    (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1332r0.txt"
    >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1332r0.txt</a>).
    </li>
     
	<li>[P1517r0] &mdash; Ryan McDougall, "Contract Requirements for Iterative High-Assurance Systems" <br>
    (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1517r0.html"
    >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1517r0.html</a>).
    </li>
	
    <li>[P2176r0] &mdash; Andrzej Krzemieński, "A different take on inexpressible conditions" <br>
    (<a href="https://isocpp.org/files/papers/P2176R0.html"
    >https://isocpp.org/files/papers/P2176R0.html</a>).
    </li>
    
    <li>[P2064r0] &mdash; Herb Sutter, "Assumptions" <br>
    (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2064r0.pdf"
    >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2064r0.pdf</a>).
    </li>
	
	<li>[P2038r0] &mdash; Andrzej Krzemieński, Ryan McDougall,
	"Proposed nomenclature for contract-related proposals" <br/>
    (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2038r0.html"
    >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2038r0.html</a>).
    </li>
	
	<li>[N4160] &mdash; Andrzej Krzemieński, "Value Constraints" <br>
    (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4160.html"
    >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4160.html</a>).
    </li>
	
	<li>[P1344r1] &mdash; Nathan Myers, "Pre/Post vs. Enspects/Exsures" <br>
    (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1344r1.md"
    >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1344r1.md</a>).
    </li>
    
    <li>[P1711r0] &mdash; Bjarne Stroustrup, "What to do about contracts?" <br>
    (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1711r0.pdf"
    >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1711r0.pdf</a>).
    </li>
    
    
</ul>

<!-- http://wiki.edg.com/pub/Wg21summer2020/CoreWorkingGroup/cwg_closed.html#2296 -->
<!-- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0348r0.html -->

</body>
</html>
