<!DOCTYPE HTML>
<html>
<head>
	<title>An alternate proposal for naming contract semantics</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: P3238R0
<br/>
Audience: SG21
<br/>
<br/>
<a href="mailto:ville.voutilainen@gmail.com">Ville Voutilainen</a><br/>
2024-04-15<br/>
</address>
<hr/>
<h1 align="center">An alternate proposal for naming contract semantics</h1>

<h2>Abstract</h2>

<p>
  The current naming of contract semantics more or less follows the form
<p>
  _______ the trueness of a predicate
</p>
and we use the words 'ignore', 'enforce', 'observe', and ostensibly,
'quick_enforce' for the blank.
</p>
<p>This proposal suggests that we should use the form
<p>
  A contract violation is treated as ______
</p>
and that we use the words 'ignored', 'enforced', 'observed' and 'erroneous'
for the blank.
</p>

<h2>So, this paper is proposing two things</h2>

<p>The more significant part proposed here is that a contract
  with the semantic where a contract violation causes instant termination
  without calling a violation handler is simply treated as Erroneous Behavior,
  with the "fallback" defined behavior being calling the violation handler.
</p>
<p>
  As far as I can see, that's perfectly reasonable. The semantic treats
  contract violations as catastrophic failures, so catastrophic that
  there is no user-defined code or any other hooks run on a violation,
  the program is just abruptly killed. For such a situation, it makes
  perfect sense to me to also allow the implementation to reject a program
  that runs into such a situation, as is already otherwise allowed for EB.
  EB allows implementation-defined diagnostics, so we can just make it have
  the defined behavior  of calling the violation handler, and then
  an implementation can avoid doing that and produce a custom diagnostic
  instead.
</p>
<p>
  So, the second part is then the renaming. I can't come up with a good
  action-verb for "be erroneous", like we have for 'ignore', 'enforce',
  and 'observe', and there's no good one for 'quick_enforce'. So I propose
  to just move that cheese and use a different approach, where the semantic
  'erroneous' is in the same grammatical position as the others that are
  past tense verbs.
</p>

<h3>A look at a hypothetical future</h3>

<p>
  We might eventually gain the ability to decide a contract semantic
  in source code. My preference for it isn't strong, but I find
  <blockquote><code>
      void f(int x) pre enforced(x >= 0);
  </code></blockquote>
  to make more sense than
  <blockquote><code>
      void f(int x) pre enforce(x >= 0);
  </code></blockquote>
  and I find 
  <blockquote><code>
      void f(int x) pre erroneous(x >= 0);
  </code></blockquote>
  to make more sense than
  <blockquote><code>
      void f(int x) pre quick_enforce(x >= 0);
  </code></blockquote>
  Or perhaps
  <blockquote><code>
      void f(int x) pre&lt;erroneous&gt;(x >= 0);
  </code></blockquote>
  as opposed to
  <blockquote><code>
      void f(int x) pre&lt;quick_enforce&gt;(x >= 0);
  </code></blockquote>
</p>

</body>
</html>
