<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
	<title>Allowing contract predicates on non-first declarations</title>

	<style>
	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;
	}
	ins {color:#00A000}
	del {color:#A00000}
	</style>
</head>
<body>

<address align=right>
Document number: P1320R0
<br/>
Audience: EWG
<br/>
<br/>
<a href="mailto:ville.voutilainen@gmail.com">Ville Voutilainen</a><br/>
2018-10-03<br/>
</address>
<hr/>
<h1 align=center>Allowing contract predicates on non-first declarations</h1>

<h2>Abstract</h2>
<p>
  This paper proposes allowing contract predicates on non-first
  declarations. The rationale of doing so is, in a nutshell,
  to allow preconditions and postconditions to be implementation
  details.
</p>

<h2>Rationale</h2>

<p>
  There are users that do not want to expose a contract checking
  mechanism in their class interfaces; there may be an English
  contract, but the language-level contract enforcement mechanism
  is an implementation detail that function declarations in
  a class definition should not expose.
</p>
<p>
  It is probable that some would suggest that such use cases
  could be handled with contract assertions in function bodies.
  The reason why this paper proposes allowing contract predicates
  on non-first declarations is that
  <ul>
    <li>In some cases, there is no body to put an assertion in;
      defaulted functions and pure virtual functions are examples
      of this.</li>
    <li>For postconditions, postconditions are guaranteed to
      be checked (when checking is enabled in the first place) at function
      exit; relying on contract assertions is more error-prone.
  </ul>
</p>

<h2>Usage examples</h2>

<p>
  We basically propose being able to do this:<pre>
    <code>
      struct X
      {
          void f();
      };

      void X::f() [[expects: foo]]
      {
         ...
      }
    </code>
  </pre>
</p>

<h2>Implementation impact, semantic restrictions</h2>

<p>
  Allowing contract predicates on a non-first declaration
  probably means that in some such cases, the checking code
  can't be laid down at the call site unless the definition
  is also seen by the compiler.
</p>
<p>
  There has been a suggestion that this ability should be modeled
  after either default arguments or after inline, but neither
  solution seems really necessary, because
  <ul>
    <li>the known use-cases are such that the contract predicates
      are desirable on a definition without having been written on
      a previous declaration.</li>
    <li>there doesn't seem to be a use case for having contracts
      on a non-defining declaration.</li>
  </ul>
</p>
<p>
  However, having said that, the following wordsmithery
  merely lifts the restriction that the first declaration
  must have the contract conditions, and allows the contract
  conditions to be placed on a defining declaration that is
  not necessarily the first declaration.
</p>

<h2>Wording</h2>

<p>
  In [dcl.attr.contract.cond]/1, modify as follows:
  <pre><blockquote>A contract condition is a precondition or a postcondition.
<ins>Either t</ins><del>T</del>he first declaration <ins>or a defining
declaration</ins> of a function shall specify
all contract conditions (if any) of the function.
Subsequent declarations shall either specify no contract
conditions or the same list of contract conditions;
no diagnostic is required if corresponding conditions
will always evaluate to the same value.
The list of contract conditions of a function shall be the same if
the <ins>non-defining</ins> declarations of that function appear in different translation units;
no diagnostic required.</blockquote></pre>
</p>
</body>

</html>
