<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">


<meta name="viewport" content="width=device-width, initial-scale=1">


<style>
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; }*/

@media (prefers-color-scheme: dark) {
	body { background: #111; color:  #ccc; }
	a { color:  #38f; }
	a:visited { color:  #a4d; }
	.sect { color:  #ccc; }
}

@media (prefers-color-scheme: light) {
	body { background:  white; color: black; }
}   

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; }

.editor { color: #4444BB; font-style: normal; background-color: #DDDDDD; }

tab { padding-left: 4em; }
tab3 { padding-left: 3em; }

.link { float: right }

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.5em; padding-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.poll { border: 1px solid black; border-spacing: 0px;  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; }

.revision   { /*color: #005599;*/ }
.grammar { list-style-type:none }

</style>

<title>The idea behind the contracts MVP</title>

</head>
<body>

<table class="header"><tbody>
  <tr>
    <th>Document number:&nbsp;&nbsp;</th><th> </th><td>P2817R0</td>
  </tr>
  <tr>
    <th>Date:&nbsp;&nbsp;</th><th> </th><td>2023-03-05</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ński &lt;akrzemi1 at gmail dot com&gt;</address>	
      </td>
  </tr>
</tbody></table>


<h1>The idea behind the contracts MVP</h1>



<p> The purpose of this document is to explain the plan that we in SG21 call <em>contracts MVP</em>.
    </p>

    
<h2>Executive summary</h2>


<p> The idea of <em>contracts MVP</em> is based on two observations. First, 
    P0542-contracts (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html"
    title="G. Dos Reis, J. D. Garcia, J. Lakos, A. Meredith, N. Myers, B. Stroustrup, &ldquo;Support for contract based programming in C++&rdquo;">[P0542R5]</a>)
    were too big to be added within a three- or even six-year time frame. Second,
    a far smaller subset of it exists that could satisfy many groups of users,
    that could be standardized faster, and still leave the room for adding the reminder of
    P0542-contracts (or superior alternatives) in subsequent iterations.</p>
    
<p> The proposed feature is small: annotations for preconditions, postconditions and assertions, plus the 
    C-assert execution model: either don't evaluate these predicates, or evaluate and stop the program if they fail.
    </p>

<p> Our goal is to encourage SG21 members to focus on the details of contract annotations first,
    so that we may have a sound and stable minimum incremental change in the Working Draft
    in the direction of the full contract support framework. In order to gather support 
    from people that need the contract support framework to provide more capabilities,
    rather than adding them just yet, we try to demonstrate how the Contracts MVP allows 
    to add the required additional features on top in a backwards compatible manner.
    We try to demonstrate that we are closing as little design doors as possible.
    </p>



<h2>The longer version</h2>

    
<p> The idea emerged after the contract support framework proposed in 
    <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html"
            title="G. Dos Reis, J. D. Garcia, J. Lakos, A. Meredith, N. Myers, B. Stroustrup, &ldquo;Support for contract based programming in C++&rdquo;">[P0542R5]</a>
            has been removed from the Working Draft just before C++20
    was finalized. There was a number of controversies and misunderstandings that prevented reaching consensus,
    and in consequence the only thing to do was to revert to the "status quo", which meant getting nothing.
    The really sad thing about it is that the core functionality of contract annotations was not controversial
    at all. It was:
    </p>
    
<ul>
    <li>the standardized way for programmers to declare contract annotations as C++ expressions,</li>
    <li>compiler to verify if these expressions are syntactically and type-system-wise correct,</li>
    <li>other programmers and reviewers to be able to see these annotations,</li>
    <li>tools to make arbitrary use of these annotations, beyond the scope of the C++ Standard.</li>
    </ul>
    
<p> A good illustration of this observation was a cry by one of WG21 members, 
    "just standardize the syntax without any semantics". Of course, one needs <em>some</em> 
    semantics associated with the syntax in order for any tool to make a use of these annotations.
    However, for the MVP (Minimum Viable Product), we try to define the minimum required semantics
    to make the syntax of contract annotations meaningful. We avoid specifying how you can control
    the compiler to make these contract annotations do different things in different builds.
    </p>

<p> The procedure in WG21 is that if a consensus about the details of a given feature cannot be reached,
    the feature is not added and we are left with the status quo: the last state of the Working Draft that WG21
    had consensus on. P0542-contracts
    (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html"
            title="G. Dos Reis, J. D. Garcia, J. Lakos, A. Meredith, N. Myers, B. Stroustrup, 
            &ldquo;Support for contract based programming in C++&rdquo;">[P0542R5]</a>)
    were considered a single feature. The lack of consensus over a number of "controls" 
    (how continuation works, are levels enough or do we want "labels"
    or "roles" or "semantics", when can contract conditions be "assumed" by the compiler) 
    meant that the entire P0542-contracts had to be removed. In other words, the status quo for
    the contract "controls" was no contracts.    
    </p>
    
<p> The goal for the <em>Contracts MVP</em> is to have a better status quo when contract "controls"
    are discussed: the status quo that is not just nothing, but something of value, even if this 
    value is small. This is based on the observation that some use cases for contracts 
    do not need any "controls" at all: they only need contract annotations to be present in the code.
    We do not want these use cases to be kept hostage by the different and incompatible
    designs of the controls, and by the disagreements between the involved parties.
    </p>
    
<p> What are the use cases that do not require any controls? First, a library/component designer
    has a tool for describing contract predicates in a single standardized way. If they 
    use this ability, the sole act of putting the preconditions and postconditions into function 
    declarations (and compiler checking if they are type-system-correct) may trigger the author
    to think harder about the design and highlight a flaw even before the program is compiled and run.
    This has the potential to prevent bugs, rather than detect the added bugs.
    </p>
    
<p> Second use case is IDEs. If they can see and understand the contract predicates (due to the
    standardized syntax and the usage of C++ expressions), they can give this information
    to the programmers in a clever way. For instance, when a programmer writes an expression
    that calls a function with a declared precondition, the IDE can display the precondition
    but instead of using the function parameter names, it can use the names of objects
    passed to the function as arguments.
    </p>
    
<p> Third use case is code analyzers that can perform static analysis or inject some instrumentation
    into the compiled binaries. This also requires controlling nothing in the compiler. 
    Many useful checks in static analyzers cannot be written today because we are missing
    contract annotations in the code. These tools require programmers to put contact annotations
    in a standardized formats. We need programmers to start putting these annotations now.
    </p>
    
<p> Fourth, programmers that use libraries/components with contract annotations can see the
    declared preconditions and postconditions, and maybe this is the first time they will 
    understand the contract and the semantics of the library/component they use. 
    This again has the potential to prevent bugs in the first place, rather than detecting
    the planed bug.
    </p>    

<p> Fifth, your favorite compiler can assign, even if in a non-conforming mode,
    arbitrary meaning to these contract annotations, such as performing runtime checks
    to log and/or abort when they fail.    
    </p>

    
<p> Finally, the important use case offered by the MVP, as we see it, is that it offers a foundation for evolution. 
    It enables compilers to implement extensions on top of the contract annotation syntax, which would be a good
    basis for the future standardization, based on implementation, deployment and usage experience. 
    The MVP has been carefully focused not to preclude any evolution path.
    </p>

<p> Importantly, the plan is <em>not</em> to deliver nothing more than the MVP for C++26.
    It is rather to secure a better status quo. Once this is done, other contract-related 
    features, such as "controls", can be attempted to be added still to C++26 without the
    risk of loosing the entire contract support from the Working Draft. Admittedly,
    one might be annoyed with the name "minimum <em>viable</em> product". It boils 
    down to what one considers viable. Maybe the choice of name is not optimal,
    and name "secure the minimum contracts status quo" would be a more precise term.
    </p>
    
<p> Our plan is to build on top of the work already done by the authors 
    <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html"
            title="G. Dos Reis, J. D. Garcia, J. Lakos, A. Meredith, N. Myers, B. Stroustrup, 
            &ldquo;Support for contract based programming in C++&rdquo;">[P0542R5]</a>.
    Because they put a lot of work into hammering the details of contract annotations, 
    we believe that by taking a subset of P0542-contracts we have a chance of succeeding
    in getting something into C++26. But even this subset has a number of issues
    that need to be addressed. The past heated discussions about contract annotation
    "semantics" and "controls" were so absorbing that they shadowed the second level of
    bugs in the design for contract annotations. For instance, during the work on the
    <em>Contracts MVP</em> we were able to pin down a number of design details missing from
    P0542-contracts; for instance,
    </p>
    
<ul>
    <li>the semantics of contract annotations in virtual functions
    in classes with multiple bases or bases being template parameters,</li>
    <li>whether contract annotations are in the immediate context,</li>
    <li>availability in freestanding implementations.</li>
    </ul>
    
<p> (For details see 
    <a href="https://isocpp.org/files/papers/P2521R3.html"
         title="Andrzej Krzemieński et al., &ldquo;Contract support — Record of SG21 consensus&rdquo;" >[P2521R3]</a>.)
    Our goal is to encourage SG21 members to focus on the details of contract annotations first,
    so that we may have a sound and stable minimum incremental change in the Working Draft 
    in the direction of 
    the full contract support framework. In order to gather support from people that need the contract 
    support framework to provide more capabilities, rather than adding them just yet, 
    we try to demonstrate how the Contracts MVP allows to add the required additional features on top
    in a backwards compatible manner. We try to demonstrate that we are closing as little design doors as possible.
    For instance, 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2182r0.html"
          title="Andrzej Krzemieński, Ryan McDougall, Joshua Berne, &ldquo;Contract Support: Defining the Minimum Viable Feature Set&rdquo;"
          >[P2182R0]</a>, which introduced the notion of <em>contracts MVP</em>,
    indicates how the continuation after failed run-time check, contract levels, global toggles and literal semantics can be added on top
    of the MVP while preserving backwards compatibility. 
    <a href="https://isocpp.org/files/papers/P2176R0.html"
          title="Andrzej Krzemieński,  &ldquo;A different take on inexpressible conditions&rdquo;"
          >[P2176R0]</a>
    discusses how inexpressible predicates can be added on top.
    <a href="https://isocpp.org/files/papers/P2784R0.html"
           title="Andrzej Krzemieński, &ldquo;Not halting the program after detected contract violation&rdquo;" >[P2784R0]</a>
    shows how the property of not halting the program upon detected contract violation can be added on top of the MVP.
    </p>

<p> We are aware that we do not address some important use cases, including these that motivated 
    <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html"
           title="G. Dos Reis, J. D. Garcia, J. Lakos, A. Meredith, N. Myers, B. Stroustrup, &ldquo;Support for contract based programming in C++&rdquo;">[P0542R5]</a>.
    By this we are not trying to imply that they are less important. 
    It is just that we see how to address the use cases that we selected faster,
    and obtain the feedback from the real life usage faster, while we can still work on re-adding
    the remaining use cases. Our goal is <em>not</em> to stop after delivering the Contracts MVP. 
    </p>
    
<p> Technically, we could have defined an even thinner scope. It has been proposed to provide only
    precondition annotations without postcondition annotations, as the latter are more problematic
    (see <a href="https://isocpp.org/files/papers/P2521R3.html"
         title="Andrzej Krzemieński et al., &ldquo;Contract support — Record of SG21 consensus&rdquo;" >[P2521R3]</a>).
    However, we refuse to do this as we feel this would cross the boundary between something that makes a coherent whole
    and a random, meaningless subset. Postconditions are necessary in certain form of program analysis where the tool
    can match preconditions of functions that consume values against the postconditions of functions that produce these values.
    This has been confirmed by an  SG21 poll on 2021-12-14:</p>
    
<p>Poll: Postconditions should be in the MVP at this time.</p>

<table class="poll">
<tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr>
<tr><td>1</td><td>7</td><td>3</td><td>4</td><td>1</td></tr>
</table>
    
<p> In a similar vein, one could question the need to provide translation mode <em>Eval_and_abort</em> in the MVP.
    However, we feel it is necessary in order to define the range of allowed program behaviors. Clearly,
    at some point, we will need more than one translation mode, and this means the same source code can 
    be used to generate different executable code, with different semantics. In order to define the range of allowed
    behaviors resulting from contract annotations, we provide the two extreme points:    
    </p>

<ul>
    <li><em>No_eval</em>, which means that compiler must not evaluate the predicates, has the following implications:
        <ol>
            <li>Putting contract annotations is not a guarantee that the program will stop upon the detected violation 
                (because it might be compiled in <em>No_eval</em> mode).
                You still have to make sure that the code is structured so that the contract annotations are never violated.</li>
            <li>The predicates may not be evaluated (because the program might be compiled in <em>No_eval</em> mode),
                don't count on their effects (side effects, or premature termination).</li>
            </ol>
        </li>
    <li><em>Eval_and_abort</em>, which means that the compiler must guarantee that the execution of the function does not 
        continue after the contract predicate returns <code>false</code>, has the following implications:
        <ol>
            <li>The predicates in your contract annotations may be evaluated, so be careful what you put inside.</li>
            <li>In the worst case your program may be terminated if a predicate evaluates to <code>false</code>,
                so make sure you structure your program so that the predicates never evaluate to <code>false</code>.</li>
            </ol>
        </li>
    </ul>
    
<p> A compiler could offer more modes, even if as a non-conformant extension, but they will fall somewhere between these two
    extreme points. This is why we need to define two translation modes in the MVP, and don't require more.</p>
    
<p> It should also be mentioned that the MVP does not propose contract
    declarations to be added to the Standard Library.
    </p>

<p> One benefit of the present MVP approach is that we were able to better expose and document the design space and challenges for the
    things like side effects in the contract predicates (see 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2570r2.html"
       title="Andrzej Krzemieński, &ldquo;Contract predicates that are not predicates&rdquo;" >[P2570R2]</a>
           and 
     <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2680r1.pdf"
           title="Gabriel Dos Reis, &ldquo;Contracts for C++: Prioritizing Safety&rdquo;" >[P2680R1]</a>),
    as well as the mutation of the non-reference function parameters referenced in postconditions 
    (see <a href="https://isocpp.org/files/papers/P2521R3.html"
         title="Andrzej Krzemieński et al., &ldquo;Contract support — Record of SG21 consensus&rdquo;" >[P2521R3]</a>).
    </p>
    
<p> One could be tempted to ask, "give me this additional switch", or "give me this additional feature",
    or otherwise some users will not be able to use it to full extent, or it will be "not viable"
    for someone. We understand that the MVP will not please all the users. However, the risk of taking the route
    of adding more and more is that we will not be able to deliver anything in the timely fashion. 
    We would end up repeating the history of "C++0x" where users had to wait like eight years for the new standard,
    or repeating the history of P0542-contracts that already aimed at being small but still needed to be 
    ripped out due to too many controversial issues. Instead, we try to demonstrate how the MVP does not 
    stand in a way of adding these features in the future, and ask for understanding. Our goal is to deliver a foundation
    in C++26 rather than something bigger in an indeterminate future.
    </p>



<h2><a class="sect" id="ack">Acknowledgments</a></h2>

<p> We are grateful to the authors of 
    <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html"
       title="G. Dos Reis, J. D. Garcia, J. Lakos, A. Meredith, N. Myers, B. Stroustrup, &ldquo;Support for contract based programming in C++&rdquo;">[P0542R5]</a>
    &mdash; G. Dos Reis, J. D. Garcia, J. Lakos, A. Meredith, N. Myers, B. Stroustrup &mdash; for their work on the contract support framework.
    The goal of the MVP is basically to reintroduce P0542-contracts, or something very similar, albeit in stages.
    </p>
    
<p> Joshua Berne, John Spicer and Timur Doumler reviewed the draft of this paper and offered improvements.
    </p>



<!-- 

Syntax surprise

One controversy remains: MVP is too small.



Bjarne's paper
-->




<h2><a class="sect" id="ref">References</a></h2>

<ul>

    <li>[P0542R5] — 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>
        <!--
        <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html"
           title="G. Dos Reis, J. D. Garcia, J. Lakos, A. Meredith, N. Myers, B. Stroustrup, &ldquo;Support for contract based programming in C++&rdquo;">[P0542R5]</a>
        -->
       
    <li>[P2114R0] — Joshua Berne, Ryan McDougall, Andrzej Krzemieński,
      "Minimal Contract Use Cases" <br>
      (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2114r0.html">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2114r0.html</a>).
      </li>
      
    <li>[P2176R0] — 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>
    <!--
    <a href="https://isocpp.org/files/papers/P2176R0.html"
          title="Andrzej Krzemieński,  &ldquo;A different take on inexpressible conditions&rdquo;"
          >[P2176R0]</a>
    -->  
      
      
    <li>[P2182R0] — Andrzej Krzemieński, Ryan McDougall, Joshua Berne,
        "Contract Support: Defining the Minimum Viable Feature Set" <br>
        (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2182r0.html">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2182r0.html</a>).
        </li> 
        <!--
        <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2182r0.html"
           title="Andrzej Krzemieński, Ryan McDougall, Joshua Berne, &ldquo;Contract Support: Defining the Minimum Viable Feature Set&rdquo;"
           >[P2182R0]</a>
        -->
      
    <li>[P2698R0] — Bjarne Stroustrup,
      "Unconditional termination is a serious problem" <br>
      (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2698r0.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2698r0.pdf</a>).
      </li>
      
    <li>[P2521R3] — Gašper Ažman, Joshua Berne, Bronek Kozicki, Andrzej Krzemieński, Ryan McDougall, Caleb Sunstrum, 
         "Contract support — Record of SG21 consensus" <br>
      (<a href="https://isocpp.org/files/papers/P2521R3.html">https://isocpp.org/files/papers/P2521R3.html</a>).
      </li>	
      <!--
      <a href="https://isocpp.org/files/papers/P2521R3.html"
         title="Andrzej Krzemieński et al., &ldquo;Contract support — Record of SG21 consensus&rdquo;" >[P2521R3]</a>
      -->
      
      
     <li>[P2570R2] — Andrzej Krzemieński, "Contract predicates that are not predicates" <br>
        (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2570r2.html">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2570r2.html</a>).
        </li>
        <!--
        <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2570r2.html"
           title="Andrzej Krzemieński, &ldquo;Contract predicates that are not predicates&rdquo;" >[P2570R2]</a>
        -->    
      
     <li>[P2680R1] — Gabriel Dos Reis, "Contracts for C++: Prioritizing Safety" <br>
        (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2680r1.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2680r1.pdf</a>).
        </li>
        <!--
        <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2680r1.pdf"
           title="Gabriel Dos Reis, &ldquo;Contracts for C++: Prioritizing Safety&rdquo;" >[P2680R1]</a>
        -->        
      
    <li>[P2784R0] — Andrzej Krzemieński,
         "Not halting the program after detected contract violation" <br>
        (<a href="https://isocpp.org/files/papers/P2784R0.html">https://isocpp.org/files/papers/P2784R0.html</a>).
        </li>	
        <!--
        <a href="https://isocpp.org/files/papers/P2784R0.html"
           title="Andrzej Krzemieński, &ldquo;Not halting the program after detected contract violation&rdquo;" >[P2784R0]</a>
        -->
      
     
      
	<!--		
	<li>[P1728R0] — Andrzej Krzemieński,
      "Preconditions, axiom-level contracts and assumptions – an in depth study" <br>
      (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1728r0.html">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1728r0.html</a>).
      </li>
	  
	<li>[P1774R8] — Timur Doumler, "Portable assumptions" <br>
		(<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1774r8.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1774r8.pdf</a>).
		</li>

	<li>[P2026R0] — Ryan McDougall et al., "A Constituent Study Group for Safety-Critical Applications" <br>
      (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2026r0.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2026r0.pdf</a>).
      </li>	
      
	<li>[P2182R0] — Andrzej Krzemieński, Ryan McDougall, Joshua Berne, "Contract Support: Defining the Minimum Viable Feature Set" <br>
      (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2182r0.html">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2182r0.html</a>).
      </li>	
			
	<li>[P2388R4] — Andrzej Krzemieński, Gašper Ažman,
      "Minimum Contract Support: either <em>No_eval</em> or <em>Eval_and_abort</em>" <br>
      (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2388r4.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2388r4.html</a>).
      </li>

			
	<li>[P1289R1] — J. Daniel Garcia, Ville Voutilainen, "Access control in contract conditions" <br>
		(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1289r1.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1289r1.pdf</a>).
		</li>
			
  <li>[P1323R2] — Hubert S.K. Tong, "Contract postconditions and return type deduction" <br>
      (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1323r2.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1323r2.html</a>).
      </li>
	
  <li>[P2388R4] — Andrzej Krzemieński, Gašper Ažman, "Minimum Contract Support: either No_eval or Eval_and_abort" <br>
      (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2388r4.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2388r4.html</a>).
      </li>
	
  <li>[P2461R1] — Gašper Ažman, Caleb Sunstrum, Bronek Kozicki, "Closure-Based Syntax for Contracts" <br>
      (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2461r1.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2461r1.pdf</a>).
      </li>	
			
  <li>[P2466R0] — Andrzej Krzemieński, "The notes on contract annotations" <br>
      (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2466r0.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2466r0.html</a>).
      </li>	

  <li>[P2487R0] — Andrzej Krzemieński, "Attribute-like syntax for contract annotations" <br>
      (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2487r0.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2487r0.html</a>).
      </li>		
	
  <li>[P2521R2] — Gašper Ažman, Joshua Berne, Bronek Kozicki, Andrzej 
Krzemieński, Ryan McDougall, Caleb Sunstrum, "Contract support — Working
 Paper" <br>
      (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2521r2.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2521r2.html</a>).
      </li>	
	  
  <li>[P2680R0] — Gabriel Dos Reis, "Contracts for C++: Prioritizing Safety" <br>
      (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2680r0.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2680r0.pdf</a>).
      </li>	

-->

			
		
	
			
</ul>



</body></html>