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.