<!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; }
dl > dt { font-style:italic; }
body { font-family: "Calibri" }
h1 { margin-top: 9ex; margin-bottom: 3ex  }
h2 { margin-top: 9ex; margin-bottom: 3ex  }

@media (prefers-color-scheme: dark) {
	body { background: #111; color:  #ccc; }
	a { color:  #38f; }
	a:visited { color:  #a4d; }
	.sect { color:  #ccc; }
    del { text-decoration: line-through; color: #EE9999; }
    ins { text-decoration: underline; color: #99EE99; }
    blockquote.std    { color: #ccc; background-color: #2A2A2A;  border: 1px solid #3A3A3A;  padding-left: 0.5em; padding-right: 0.5em; }
    blockquote.stddel { text-decoration: line-through;  color: #ccc; background-color: #221820;  border: 1px solid #332228;  padding-left: 0.5em; padding-right: 0.5em; ; }
    blockquote.stdins { text-decoration: underline;  color: #ccc; background-color: #182220;  border: 1px solid #223328; padding: 0.5em; }
    table { border: 1px solid #ccc; border-spacing: 0px;  margin-left: auto; margin-right: auto; }
}

@media (prefers-color-scheme: light) {
	body { background:  white; color: black; }
    del { text-decoration: line-through; color: #8B0040; }
    ins { text-decoration: underline; color: #005100; }
    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 { border: 1px solid black; border-spacing: 1px;  margin-left: auto; margin-right: auto; }
}


.comment em { font-family: "Calibri"; font-style:italic; }
p.example   { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }
div.poll { 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; font-family: "Consolas", "Lucida Console", monospace; font-size:80% }


table.header { border: none; border-spacing: 0;  margin-left: 0px; font-style: normal; }
td.header { border: none; border-spacing: 0;  margin-left: 0px; font-style: normal; }
.header { border: none; border-spacing: 0;  margin-left: 0px; font-style: normal; }
table.poll { border: 1px solid black; border-spacing: 0px;  margin-left: 0px; font-style: normal; }

th { text-align: left; vertical-align: top;  padding-left: 0.4em;  /*padding-right: 0.4em; border-bottom:1px dashed;*/ }
td { text-align: left;  padding-left: 0.4em; padding-right: 0.4em; /*border-right:1px dashed; */}
tr { border: solid; border-width: 1px 0; border-bottom:1px solid blue }


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

</style>

<title>A takeaway from the Tokyo LEWG meeting on Contracts MVP</title>

</head>
<body>  

<table class="header"><tbody>
  <tr>
    <th>Document number:&nbsp;&nbsp;</th><th> </th><td class="header">P3198R0</td>
  </tr>
  <tr>
    <th>Date:&nbsp;&nbsp;</th><th> </th><td class="header">2024-03-29</td>
  </tr>
  <tr>
    <th>Audience:&nbsp;&nbsp;</th><th> </th><td class="header">SG21</td>
  </tr>
  <tr>
    <th>Reply-to:&nbsp;&nbsp;</th><th> </th><td class="header">
        <address>Andrzej Krzemieński &lt;akrzemi1 at gmail dot com&gt;</address>
    </td>
  </tr>
</tbody></table>




<h1>A takeaway from the Tokyo LEWG meeting on Contracts MVP</h1>


<p> This paper lists potential modifications to be applied to 
    <a href="https://isocpp.org/files/papers/P2900R6.pdf" title="Joshua Berne, Timur Doumler, Andrzej Krzemieński, “Contracts for C++”">[P2900R6]</a>
	(Contracts for C++) based on the feedback obtained from people present at the LEWG meeting in Tokyo on the Contracts MVP.
    This includes the use case in 
    <a title="Louis Dionne, Yeoul Na, Konstantin Varlamov, “Feedback on the scalability of contract violations handlers in P2900”">[P3191R0]</a>
       (Feedback on the scalability of contract violations handlers in P2900).
	</p>



<h2>1. The underlying type of enums is redundantly specified to as <code>int</code></h2> 

<p> The enumeration declarations in the paper have the form</p>

<pre>enum class contract_kind : int {
  pre = 1,
  post = 2,
  assert = 3
};
</pre> 

<p>The underlying type of an enumeration when you do not specify it is <code>int</code> anyway.
   Specifying it explicitly is redundant and not harmonized with the rest of the Standard library description.</p>

<p><strong>Proposal 1.</strong> Drop the explicit specification of the 
underlying type; 
   mention in the front matter of P2900 that the design intent is that 
the underlying type needs to be large enough to hold all possible values
 (including any vendor-provided ones, which start at 1000).</p>




<h2>2. Conflating the contract violation with the predicate throw detection</h2> 

<p>In <a href="https://isocpp.org/files/papers/P2900R6.pdf" title="Joshua Berne, Timur Doumler, Andrzej Krzemieński, “Contracts for C++”">[P2900R6]</a>
    the handler is called in two cases:

</p><ol>
<li> when a contract is violated (the predicate returned <code>false</code>),</li>
<li> when the evaluation of the predicate throws.</li>
</ol>

<p>The second case is nothing like the contract violation, yet the library names used during the handling of this situation
   still have "contract violation" in their name.
   </p>
   
<p> This interacts with <a title="Louis Dionne, Yeoul Na, Konstantin Varlamov, “Feedback on the scalability of contract violations handlers in P2900”">[P3191R0]</a>
    which is concerned with having to generate a <code>try</code>-<code>catch</code> block for every predicate in
    order to satisfy the requirements.
    
</p><p><strong>Proposal 2.</strong> Introduce a different nomenclature to P2900. Use term "contract verification failure" in place of "contract violation". 
   Rename:</p>  

<ol>
<li> <code>contract_violation</code> --&gt; <code>contract_verification_failure</code>,</li>
<li> <code>handle_contract_violation</code> --&gt; <code>handle_contract_verification_failure</code>.</li>
</ol>

<p><strong>Proposal 3.</strong> Use separate handlers for the two situations.</p>  
  
  
  
<h2>3. Redundant word "contract" in qualified names</h2>   

<p> Library names reside in namespace <code>contracts</code> and all but one have prefix <code>contract</code>:</p>

<pre>std::contracts::contract_violation
std::contracts::contract_kind 
</pre>
 

<p><strong>Proposal  4.</strong> Drop namespace <code>contracts</code>.</p> 
<p><strong>Proposal 5.</strong> Rename the entities to avoid prefix <code>contract</code>:</p> 

<ol>
<li> <code>contract_kind</code> --&gt; <code>assertion_kind</code>,</li>
<li> <code>contract_semantic</code> --&gt; <code>evaluation_semantic</code>.</li>
</ol>


<h2>4. Too verbose name <code>invoke_default_contract_violation_handler</code></h2> 

<p>The name is too long, and prefix <code>invoke_</code> brings no value.</p>

<p><strong>Proposal 6.</strong> Rename to <code>default_contract_violation_handler</code>.</p>
<p><strong>Proposal 7.</strong> Rename to <code>default_handle_contract_violation</code>.</p>
 

<h2>5. Provide rationale for adding a namespace</h2> 


<p> The Standard library avoids using nested namespaces. Departure from this requires a strong rationale. </p>

<p> Our present rationale is:</p>

<ol>
<li> If these names will be used at all, they will be used in a single translation unit.</li>
<li> We intend to extend the set of entities related to violation handling in the future. We want to
     reserve the space for introducing names that would potentially clash with names in <code>std</code>.
     </li>
<li> When user does <code>import std;</code> we do not want the handler-related functions to be imported.</li>
</ol>



<h2>6. Add another evaluation mode (<a title="Louis Dionne, Yeoul Na, Konstantin Varlamov, “Feedback on the scalability of contract violations handlers in P2900”">[P3191R0]</a>)</h2> 

<p><a title="Louis Dionne, Yeoul Na, Konstantin Varlamov, “Feedback on the scalability of contract violations handlers in P2900”">[P3191R0]</a>
    argues that the present evaluation mode <em>enforce</em> causes unnecessary performance compromises due to the contract violation handler machinery.</p>
   <p>It requests a fourth, performance-sensitive predicate evaluation semantic where:</p>


<ul>
<li> the predicate is runtime-evaluated,</li>
<li> no violation handler is invoked,</li>
<li> program is stopped in an implementation-defined way.</li>
</ul>	
    
    
<h2>7. Detection of throwing is too expensive (<a title="Louis Dionne, Yeoul Na, Konstantin Varlamov, “Feedback on the scalability of contract violations handlers in P2900”">[P3191R0]</a>)</h2> 

<p><a title="Louis Dionne, Yeoul Na, Konstantin Varlamov, “Feedback on the scalability of contract violations handlers in P2900”">[P3191R0]</a>
   argues that the requirement on the implementation to detect a throw 
from the predicate implies a code bloat in terms of injected <code>try</code>-<code>catch</code> blocks.</p>

<p><strong>Proposal 8.</strong> When a predicate throws, call <code>terminate()</code> directly.</p>
<p><strong>Proposal 9.</strong> Require a predicate to be <code>noexcept</code>.</p>
<p><strong>Proposal 10.</strong> Just propagate such exception normally.</p>
<p><strong>Proposal 11.</strong> Implementation-defined between <code>terminate()</code> and a violation handler.</p>


<h2>8. Don't force implementations to use <code>abort()</code> (<a title="Louis Dionne, Yeoul Na, Konstantin Varlamov, “Feedback on the scalability of contract violations handlers in P2900”">[P3191R0]</a>)</h2> 
       
<p> Calling <code>std::abort()</code>:</p>

<ul>
<li> has some performance implications,</li>
<li> requires importing a library symbol,</li>
<li> performs actions, such as raising <code>SIGABRT</code>
    that might be undesired when handling a contract violation.</li>
</ul>	
  
<p><strong>Proposal 12.</strong> Revert to terminating in an implementation-defined manner.</p>  


<h2>9. ODR-concerns about handler replacement (<a title="Louis Dionne, Yeoul Na, Konstantin Varlamov, “Feedback on the scalability of contract violations handlers in P2900”">[P3191R0]</a>)</h2> 


<p><a title="Louis Dionne, Yeoul Na, Konstantin Varlamov, “Feedback on the scalability of contract violations handlers in P2900”">[P3191R0]</a>
   observes that the mechanism required for installing a custom violation handler à la <code>operator new</code> has the potential to trigger a non-benign
   ODR violation. (<a title="Louis Dionne, Yeoul Na, Konstantin Varlamov, “Feedback on the scalability of contract violations handlers in P2900”">[P3191R0]</a>
   calls this item unactionable.)</p>
   
<p><strong>Proposal 13.</strong> Preserve the interface of the handler, but say that it is implementation-defined how it is installed.</p>   
   
   
<h2>10. Do not use word <code>contract</code> for names in namespace <code>contracts</code></h2> 

<p> Assuming that namespace <code>contracts</code> stays, do not use word <code>contract</code> for entities defined in that namespace.
    This is to avoid repetition.</p>
    
<p> The initial response from SG21 was that names in the namespace are not mechanically prefixed with "contract". 
    Not all names in the namespace start with "contract", only those where omitting the name looses meaning.</p>

<p><strong>Proposal 14.</strong> Rename <code>contract_violation</code> to <code>violation</code>.</p>
<p><strong>Proposal 15.</strong> Rename <code>invoke_default_contract_violation_handler</code> to <code>invoke_default_violation_handler</code>.</p>

<h1>References</h1>


<ul>
<li>[P2900R6] — Joshua Berne, Timur Doumler, Andrzej Krzemieński,
    "Contracts for C++", <br>
    (<a href="https://isocpp.org/files/papers/P2900R6.pdf">"https://isocpp.org/files/papers/P2900R6.pdf"</a>).
    </li>
    <!--
    <a href="https://isocpp.org/files/papers/P2900R6.pdf"
       title="Joshua Berne, Timur Doumler, Andrzej Krzemieński, &ldquo;Contracts for C++&rdquo;">[P2900R6]</a>
    -->
 
<li>[P3191R0] — Louis Dionne, Yeoul Na, Konstantin Varlamov,
    "Feedback on the scalability of contract violations handlers in P2900", <br>
    <!--(<a href="https://isocpp.org/files/papers/P2900R6.pdf">"https://isocpp.org/files/papers/P2900R6.pdf"</a>)-->.
    </li>
    <!--
    <a 
       title="Louis Dionne, Yeoul Na, Konstantin Varlamov,, &ldquo;Feedback on the scalability of contract violations handlers in P2900&rdquo;">[P3191R0]</a>
    --> 

</ul>




</body></html>