<html>

<head>
  <meta name="description" content="Proposal for C++ Standard">
  <meta name="keywords" content="C++,cplusplus,wg21">
  <meta name="author" content="Alisdair Meredith">

  <title>Proposal Template</title>

  <style type="text/css">
    ins {background-color:#A0FFA0}
    del {background-color:#FFA0A0}
    p {text-align:justify}
    li {text-align:justify}
    blockquote.note
    {
      background-color:#E0E0E0;
      padding-left: 15px;
      padding-right: 15px;
      padding-top: 1px;
      padding-bottom: 1px;
    }
  </style>
</head>

<body>
<table>
<tr>
  <td align="left">Doc. no.</td>
  <td align="left">D1793R0</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2019-06-17</td>
</tr>
<tr>
  <td align="left">Project:</td>
  <td align="left">Programming Language C++</td>
</tr>
<tr>
  <td align="left">Audience:</td>
  <td align="left">Evolution Working Group</td>
</tr>
<tr>
  <td align="left">Reply to:</td>
  <td align="left">Alisdair Meredith &lt;<a href="mailto:ameredith1@bloomberg.net">ameredith1@bloomberg.net</a>&gt;</td>
</tr>
</table>

<h1>Simplifying Contract Syntax</h1>

<h2>Table of Contents</h2>
<ol>
<li><a href="#rev.hist">Revision History</a></li>
  <ul>
  <li><a href="#rev.0">Revision 0</a></li>
  </ul>
<li><a href="#1.0">1 Introduction</a></li>
<li><a href="#2.0">2 Stating the problem</a></li>
<li><a href="#3.0">3 Other Directions</a></li>
<li><a href="#4.0">4 Formal Wording</a></li>
<li><a href="#5.0">5 References</a></li>
</ol>


<h2><a name="rev.hist">Revision History</a></h2>

<h3><a name="rev.0">Revision 0</a></h3>
<p>
Original version of the paper for the 2019 pre-Cologne mailing.
</p>

<h2><a name="1.0">1 Introduction</a></h2>
<p>
The grammar for contracts is a little more verbose than it needs to be.
This paper recommends we take this last change to simplify, before the
standard is finalized.  This paper proposes no <tt>functional</tt>
changes, merely simplification of how we express the current semantics.
</p>


<h2><a name="2.0">2 Stating the problem</a></h2>
<p>
The grammar for contracts reflects the evolutions of the design, and a
few reasonable use cases appear more verbose than they need to be.  As
we are going to live with this syntax choice for the next few decades,
we should take the opportunity to simplify and avoid future embarrassment.
</p>

<p>
The use case is simple.  When we declare pre and post conditions, we
assume the default checking level, leaving simple syntax for the
common case:
</p>
<blockquote><pre>
int test(int value)
  [[pre: value &gt; 0]]
  [[post result: result &lt; 0]]
{
   return -value;
}
</pre></blockquote>

<p>
Similarly, for <tt>assert</tt> contract checks, we can assume the default
checking level:
</p>

<blockquote><pre>
int test(int value)
  [[pre: value &gt; 0]]
  [[post result: result &lt; 0]]
{
  [[assert: value &lt; 100]];

   return -value;
}

</pre></blockquote>

<p>
However, when it comes to asserting audit and axioms checks, we end up with
two tokens:
</p>


<blockquote><pre>
int test(int value)
  [[pre: value &gt; 0]]
  [[post result: result &lt; 0]]
{
  [[assert audit: value &lt; 100]];
  [[assert axiom: value &gt;   0]];

   return -value;
}
</pre></blockquote>

<p>
Notice that <tt>assert</tt> is not disambiguating anything here, and could
as easily be inferred as the default checking level.  Hence, this paper
proposes simplifying the grammar in this case to omit the <tt>assert</tt>
</p>

<blockquote><pre>
int test(int value)
  [[pre: value &gt; 0]]
  [[post result: result &lt; 0]]
{
  [[assert: value &gt;   0]];
  [[audit:  value &lt; 100]];
  [[axiom:  value !=  0]];

   return -value;
}
</pre></blockquote>

<p>
Note that <tt>assert</tt> appears more like <tt>audit</tt> and <axiom</tt>
in this context, which leads to the second suggestion: rename the
<tt>default</tt> checking level to <tt>assert</tt>.  This would clean up
a remarkable cause of confusion I have hear in many discussions of the
contract facility, where different uses of the term 'default' lead to
people arguing at cross-purposes to each other.
</p>

<p>
With this final change, the grammar cleanup is relatively straight forward,
see proposed wording below.
</p>

<blockquote><pre>
</pre></blockquote>



<h2><a name="3.0">3 Other Directions</a></h2>
<p>
The main purpose of <tt>pre</tt> and <tt>post</tt> is to disambiguate their
different semantic intent when adding a contract checking attribute to a
function declaration.  If we were to make the optional <i>result</i> field
mandatory, that would also serve to disambiguate, and allow us to further
simplify by proving only a contract checking level in all cases.
</p>

<blockquote><pre>
int test(int value)
  [[assert: value &gt; 0]]
  [[axiom result: result &lt; 0]]
{
  [[assert audit: value &lt; 100]];
  [[assert axiom: value &gt;   0]];

   return -value;
}
</pre></blockquote>


<p>
While this might have been considered 12-18 months ago, that seems too
radical a departure from our established convention at this point.
Further, <tt>pre</tt> and <tt>post</tt> provide helpful syntactic cues
to the reader.  They may be strictly superfluous in the analysis above,
but they still provide value, and retain more of the design space for
future exensions - otherwise we are restricted on giving meaning to
special identifiers in the <i>result</i> position, that would become
ambiguous with a pre-condition using that special identifier.
</p>


<h2><a name="4.0">4 Formal Wording</a></h2>
<p>
Make the following changes to the specified working paper:
</p>

<blockquote>


<h4>9.11.4.1 Syntax [dcl.attr.contract.syn]</h4>
<blockquote><pre>
contract-attribute-specifier :
[ [ expects contract-level<sub>opt</sub> : conditional-expression ] ]
[ [ ensures contract-level<sub>opt</sub> identifier<sub>opt</sub> : conditional-expression ] ]
[ [ <del>assert</del> contract-level<del><sub>opt</sub></del> : conditional-expression ] ]

contract-level :
  <ins>assert</ins><del>default</del>
  audit
  axiom
</pre></blockquote>

</blockquote>


<h2><a name="5.0">5 References</h2>
<ul>
  <li>
   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4810">N4810</a> 
   Working Draft, Standard for Programming Language C++,
   Richard Smith
  </li>
</ul>


</body>
</html>
