Predicate is unevaluated

When predicate evaluation is not enabled, it seems clear that there is just one reasonable choice of semantics; that execution enters the function body. However, that does not mean that an implementation should completely ignore predicates; logic errors that involve predicates can still be diagnosed and can still affect observed program behavior. The following example contains such an error; the precondition unconditionally dereferences parameter p but the function body has behavior that is conditional on p being a null pointer. Implementors should be encouraged to diagnose such issues as a matter of QoI. Static analysis tools commonly detect and report issues like this.

int f(int *p)
  PRE( *p < 5 )
{
  if (!p)
    return 0;
  return *p;
}

Note that the logic error in the above example matches the one in the following example using assert. One of the benefits that contracts brings is that observance of the logic error is not dependent on a build mode; the predicate above is always present whereas the expression in the assert expression below is hidden from the compiler when compiling with NDEBUG defined.

int f(int *p)
{
  assert( *p < 5 );
  if (!p)
    return 0;
  return *p;
}

Predicate evaluation yields a true result

When predicate evaluation is enabled and evaluation yields a true result, it is likewise clear that the desired behavior is that execution enters the function body. The concerns about potential logic errors above are likewise applicable.

Predicate evaluation yields a false result

When predicate evaluation is enabled and evaluation yields a false result, this proposal calls for a contract violation handler to be invoked. Unlike P2811R1^[P2811R1], this proposal delegates all responsibility for handling the violation to the handler. If program termination is desired (the "enforce" or "Eval_and_abort" semantic described in other papers), then it is up to the handler to perform that termination (perhaps by calling the implementation-provided handler). if it is desired to continue program execution (the "observe" or "Eval_and_log" semantic), then the handler can simply return; this is consistent with the behavior of a contract violation when contract checking is not enabled.

Predicate evaluation encounters undefined-behavior

It is unlikely to be surprising that the proposed semantic for undefined-behavior is undefined-behavior. This case is explicitly called out to acknowledge previous discussion of P2680R1^[P2680R1]. Though consensus for that proposal has not been established, the potential for another proposal that seeks to constrain undefined-behavior within contract predicates to attain consensus is well recognized. In the meantime, this proposal reflects the status quo.

Predicate evaluation or violation handler throws

It remains unclear what semantics are desired in the case of exceptions that propagate from a predicate evaluation or violation hander invocation; particularly with regard to a function declared with a noexcept exception specification. Does such an exception originate from within the function such that it immediately hits the noexcept boundary? Or is it considered to have been thrown from the caller side of the function as is the case for exceptions thrown during parameter initialization? If the latter, how does that interact with the noexcept operator? Due to these open questions, this paper proposes that throwing an exception from a predicate or a violation handler have unspecified behavior until consensus is established for a direction as P2780R0^[P2780R0] seeks to do.

Predicate evaluation or violation handler calls std::longjmp

The open questions regarding exception handling don't apply to calls to longjmp since questions of noexcept exception specifications and the noexcept operator don't apply. The absence of a reason to deviate longjmp behavior in contract contexts therefore motivates making use in these contexts well-formed.