
                                                    Paper number: d1486r0
                                                    Topic: Contracts
                                                    Author: John Lakos
                                                    Email: jlakos@bloomberg.net
                                                    Audience: EWG




             United Amendment to Contracts Facility for C++20

                         John Lakos - Bloomberg LP

                    Revised: Wednesday, February 13, 2019

                                 Abstract

Contracts are already part of the current WP for C++20, yet there is a known
defect (see section 1) that was introduced during transcription after
Rapperswil.  Despite our best efforts, agreement on how best to amend the
wording in the WP remains elusive.  This paper proposes that we start with the
intersection of p1290r1 and p1429r0, using the agreed upon default levels
(which fixes the defect), and then add back mutually agreeable features --
approved by consensus straw-poll votes, one by one -- until no more consensus
agreement can be reached.  This maximal intersection of agreement will then
become the united consensus amendment that the preponderance of original
coauthors implicitly (if not explicitly) support.

1. Introduction

The contracts facility adopted into the current working paper in Rapperswil
this past June has a critical flaw that makes it inconsistent with the
original (and current) intent of the overwhelming preponderance of the authors
of p0542r5, the joint paper on which it is based.  This defect was the result
of a transcription error during the formal wording process in association with
CWG.  As worded, the WP suggests that a 'default'-level or 'audit'-level
contract-checking statement (CCS) can have only two possible semantics (as
defined in p1333r0): 'check_never_continue' (when enabled) and 'assume' (when
disabled).  Although the ability for contracts to be used for
optimization purposes was a noted selling point of this language-based version
of the facility (as compared with, say, n3604), the absence of runtime
checking was never intended to imply assumption by default.

Between the Rapperswil (June'18) and San Diego (September'18) meetings, there
was much discussion on the reflector regarding contracts.  A preview of an
omnibus "area" paper, describing the landscape of possible future extensions
for contracts (that would become p1332r0), was released on the reflector prior
to San Diego.  During that meeting, it was agreed that the WP as worded was
not desirable, but the drive-by fix to eliminate all assumption from
runtime-checkable contracts left many (including several co-authors of p0542r5)
feeling needlessly disenfranchised.

Following San Diego, two distinct ways of addressing this issue -- p1290r0
(Garcia) and p1333r0 and p1334r0 (Berne & Lakos) -- were included in the
October'18 post-meeting mailing, along with the long-term overview paper,
p1332r0 (Berne, Burgers, Rosen, and Lakos) and another non-proposal, p1335r0
(Lakos), contrasting the approaches of Garcia and Berne et al.  An almost
unprecedented amount of discussion has since transpired -- both privately and
on the reflector.  Despite genuine best efforts on both sides, we remain unable
to reach a consensus proposal on our own.

The two current proposals to address the agreed-upon major defect (see above)
as well as some other small tweaks are p1290r1 (Garcia) and p1429r0 (Berne &
Lakos).  Both papers have been refined and in some cases streamlined and
simplified, but neither position has changed substantially since San Diego.

The sad thing is that almost everyone using contracts would not care (or even
know) about the dissimilarities embedded in these proposals.  The main
differences center around (1) how levels are mapped to specific semantics at
translation time, and (2) whether it is possible for checks that continue after
a failed predicate and checks that don't to coexist within the same TU.  The
former makes a difference for only those who care to distinguish (at
translation time) between running checks that are reasonably fast and those
that are not.  The latter applies only to larger development efforts where some
of the code has contract-checking in place in production, and management wants
to add new, as of yet untried checks that might detect latent (yet heretofore
"benign") defects.

2. Road Map

It is, I think, everyone's position that we do not want to do anything that
would compromise an ideal design in C++23, yet we all feel we must repair the
defect that accidentally slipped into the WP in Rapperswil.  To that end, we
now propose starting by identifying the intersection of agreement between the
two papers -- r1290r1 and r1429r0 -- and then making that the final, unified
proposal that we can all endorse, knowing full well that the result may well
lack features that are currently available even in the status quo.  The next
step would then be to add back features -- one by one -- during our EWG
meeting on Monday, February 18, 2019, in Kona (taking straw-poll votes
for guidance) until maximal consensus agreement is achieved.  Finally, this
intersection of agreement would be submitted as our consensus amendment to the
WP for contracts in C++20.

In particular, the initial starting point is to adopt the same (see p1325r0)
default semantics (see p1334r0) for levels proposed in both p1290r1 and
p1429r0:

    default='check_never_continue'
    audit='ignore'
    axiom='assume'

If we remove the ability to alter these defaults, the defect in the WP is
eliminated and the straw polls -- (1) eliminating UB from 'default'-level and
'audit'-level CCSs, and (2) requiring it for 'axiom'-level CCSs -- taken in
San Diego is achieved!  Done!  The next steps will be to consider (a) if and
how we modify level semantics per TU and also (b) whether it is permissible to
specify contract-checking statements with varying continuation semantics within
a TU.  Finally, it has been widely suggested that we add a TU-wide master
"disable flag" for the entire contract-checking facility.  We think such a flag
makes sense anyway and will be absolutely necessary if we cannot come to
agreement on precisely how the default semantics for the various CCS levels
are to be overridden on the build line (for consumption during translation).

3. Next Steps

After Meeting Monday in Kona, our plan is to take whatever we have agreed to,
make that "intersection of agreement" the next revision of this paper, and
submit it as our united contracts-amendment proposal for consideration by the
greater C++ standards community.  It is our hope that all of the coauthors of
p0542r5 will join in getting as much of a loaf as we reasonably can under
these difficult and tightly time-constrained circumstances.
