Paper number: p1487r0 Topic: Contracts Author: John Lakos Email: jlakos@bloomberg.net Audience: EWG User Experience with Contracts That Work John Lakos - Bloomberg LP Revised: Wednesday, February 13, 2019 Abstract This paper is not a proposal, but merely a placeholder for a short presentation that I plan to give early on Monday, February 18, 2018 in Kona highlighting just the salient aspects of the more comprehensive information contained herein. At that time, I hope to describe briefly the history of our experience with our (library-based) contract-checking facility (CCF) developed at Bloomberg, upon which the (language-based) CCF (p0580r5) adopted into the working paper (WP) for C++20 is based. 1. Time line. 2004 - The first incarnation of a library-based contract-checking facility (CCF) know as 'bde_assert' is conceived by John Lakos in Bloomberg's BDE group, which he created back in 2001 and still runs. 2005 - First known use of 'bde_assert' in an application group (mortgages) outside of software infrastructure (SI) at Bloomberg. 2008 - The facility is given a major facelift, re-implemented with more fine-grained control, and adorned with copious usage examples. 2009 - The ideas behind design-by-contract (DbC), defensive programming (DP), and undefined behavior (UB) along with the distinction between *wide* contracts (those having no preconditions) and narrow ones (those that do have precondition) are first presented outside of Bloomberg at ACCU'09 in Oxford England as part of a much larger presentation (with Andrei Alexandrescu in attendance). 2010 - Bloomberg's entire CCF is demoted to the 'bsls' package in Bloomberg's own overlay implementation of the standard library (which has always supported PMR-style memory allocators and been implemented exclusively in module-like components). It is well know -- even back then -- that the ability to install a returning violation handler is an absolute requirement for incorporating new contract checks into older programs that heretofore have made no use of our 'bsls_assert'-based CCF. Moreover, even back then our contract-assertion-testing facility, 'bsls_asserttest', relied on the ability of a test handler to throw a test-violation exception from a deliberately failed check. 2011 - [March] It is made clear to the C++ Standards committee by Alisdair Meredith -- in (n3279) "Conservative use of 'noexcept' in the Library" -- the reasoning behind why narrow contracts should not be made 'noexcept' (with Nicolai Josuttis in attendence). 2011 - [April] The 'bsls_assert' facility along with the distinction between *language* undefined behavior (a.k.a. "hard" UB), *library* undefined behavior (a.k.a. "soft" UB), and how contract checking statements (CCSs) are tested effectively using exceptions was first presented outside Bloomberg at at ACCU'11 (with scott Myers in attendance). 2012 - Bloomberg's BDE team first begins to learn from its client base that having anything less than essentially all available contract checks active by default when runtime checking is enabled is unintuitive, error prone, and entirely unacceptable. Bloomberg then begins to consider reducing number of runtime contract-checking levels from four to three: 'opt' (not available in C++20), default, and safe (a.k.a. audit in C++20). 2012 - [September] The first open-source version of our previously proprietary implementation of the bsl (Bloomberg Standard Library) package group -- composed of packages of components (which would become the forerunners of what are now proposed to become modules) -- liberally incorporating the use 'bsls_asert' (which would become the forerunner of today's contract-checking facility in C++20), along with support for polymorphic memory allocators, 'bslma_allocator' (which would become the forerunner for the PMR -- polymorphic memory resource -- in C++17). 2013 - [March] The first C++ Standards paper describing a library-based, (macro-laden) 'bsls_assert'-like CCF, n3604, is proposed by Lakos & Zakharov, entitled "Centralized Defensive-Programming Support for Narrow Contracts" 2013 - [April, May] Our component-based methodology, Lakos'96 (and even more so, Lakos'19), illustrated by our open-sourced BDE code base and highlighting the liberal use of 'bsls_assert', is presented at ACCU'13 and C++Now'13, respectively. 2014 - [June] The final incarnation of our bsls_assert-based proposal *not* incorporating language-level optimization as a feature (n4075) "Centralized Defensive-Programming Support for Narrow Contracts (Revision 6)" by Lakos, Zakharov, and Beels, was shot down in flames in the June plenary meeting in Rapperswil,'14 -- largely due to its heavy dependence on macros (Gaby Dos Reis, Chandler Carruth, Pablo Halpern, and lots more were in attendance). 2014 - [September] The same presentation that was given at ACCU'11 was reprised (virtually unchanged) at (the first) CppCon'14 (with Bjarne Stroustrup in attendance). 2014 - [October] The first language-based proposal conceived solely from Bloomberg's (library-based) usage experience (n4135) "Language Support for Runtime Contract Validation (Revison 8)" is submitted by Lakos, Zakharov, Beels, and Myers. In fact, contracts as we know them today might never have come to be had Nathan Myers, then a member of the BDE team at Bloomberg, not come along and rescued it from oblivion by suggesting that we incorporate the potential for compiler optimization as an additional carrot to attract users. By all accounts, that was a very good idea, and the rest is history! 2015 - [February] A follow-up proposal (n4378) "Language Support for Contract Assertions (Revision 10)" by the same authors, and an FAQ discussing the rationale behind n4378 by Nathan Myers alone (n4379) were submitted in support of the Bloomberg user experience. 2015 - A major outage at Bloomberg resulting from continuing after a proper CCS correctly diagnosed a defect because the currently installed violation handler returned normally (as opposed to aborting), permitting the application to enter soft UB with consequences far worse than crashing. This would not have been a problem if normal return was allowed for just new CCSs in running production code, but the singleton handler in our library-based CCF -- which was our only means of controlling continuation -- either returned or didn't, not just per TU, but for the entire application! This outage was so severe that it prompted senior management to issue this fiat: Once a CCS is made active (i.e., "check [maybe continue]" in P1333r0) and proved to be both correct and complied with by all known clients, it is to be changed to never return (i.e., "check [never continue]" in P1333r0), and must never be allowed to continue again. Now that we had CCSs active in client code, adding new checks or even enabling existing ones became infeasible for clients of the existing system. Enabling additional CCSs at Bloomberg stagnated for literally years. 2016 - [May] A brand new joint contracts facility -- elegantly merging the compile-time static-analysis declaration-decorating capabilities of n4435 (microsoft) with the runtime-checking and violation handling capabilities of n4378 -- was proposed in p0380r0 authored jointly by Dos Reis, Garcia, Lakos, Meredith, Myers, and Stroustrup. This was the unified notion of a CCF that would evolve to become the CCF in C++20. 2017 - [August] Rostislav (Slava) Khlebnikov is hired as a senior software developer into the BDE team (initially in the London office) from hi previous employer (in Germany). While awaiting work authorization to move to London, he and John Lakos conspired to write the first in a series of seminal white paper entitled, "Contracts, Undefined Behavior, and Defensive Programming", which has proved invaluable in communicating the proper use of contracts in an industrial setting. 2017 - [September] Bloomberg's senior management realizing, among other features, the importance of a proper language-based contract-checking facility in C++, made the multi-year commitment to engage the services of Dr. Andrew Sutton to create a prototype version of the GCC and clang compilers consistent with the needs of even the most demanding large-scale software development companies (e.g., Google). 2018 - [June] Paper p0542r5, "Support for contract based programming in C++" by the same six authors that wrote p0380r0 was adopted into the C++20 WP. During transcription, however, a subtle defect wherein disabled CCSs were -- by default -- permitted to assume (i.e., 'assume' in p1333r0) the truth of any unchecked predicate -- in sharp contrast to what I remain convinced was the original (i.e., as of p0380r0), if not necessarily the current (i.e., after p0542r5) intent of *all* of its authors. 2018 - [June] Nathan Burgers agrees to transfer into the BDE group from a sister SI area within Bloomberg. Nathan is "somewhat" of a (self-admitted) compiler- and language-design nerd (much like I presume Bjarne was at Nate's stage in his career). Nate is leading our efforts to prototype and (soon) provide an industrial-strength contract-checking facility in Python (and eventually Javascript and Java). His prototype has an uncanny similarity to what is currently described in the C++20 WP -- replete with almost *zero* cost for disabled 'expects' and 'ensure' CCS clauses affixed to client-facing signatures. What's more, he was able to achieve this prototype without having to alter the language itself whatsoever! 2018 - [July] Joshua Berne is hired into the BDE group as a (very) senior software engineer and charged with creating a distinct but otherwise identical (to bsls_assert) CCF, which he named 'bsls_review', for introducing new (continuing) CCSs that check (and might continue) while insisting that all established CCSs check but never continue, thus allowing both kinds of semantics from p1333r0 -- namely "check (never continue)" and "check (maybe continue)" to coexist within a single translation unit (TU). (N.B., These two distinct *roles* would be captured and generalized to a allow a new tag in a CCS corresponding to its *role* in the SDLC in p1332r0). 2018 - [August] Management, acknowledging the importance of modules as an architectural feature (as well as an organization one), agree to appoint Nate as Bloomberg's "goto person" for modules within the Standardization process. Nate is responsible for reviewing all module-related functionality proposed for incorporation into the C++ language and, in particular, verifying that it satisfies p0678r0, "Business Requirements for Modules" (Lakos). What's more, Nate is charged with detecting all potential interactions between possible implementation of contract and module features (of which there are already known to be many). Nate's deep knowledge of compilers, language design C++ and Python (among others) coupled with his penitent to apply them to standards-related work in service to large-scale software engineering make him uniquely qualified in his role here at Bloomberg. 2018 - [October] Almost unprecedented discussion of what can and should be done to address the widely acknowledged defect introduced in Rapperswil, resulted in an omnibus paper, p1332r0 (Berne, Burgers, Rosen, and Lakos), describing a possible long-term roadmap for contracts in C++ well beyond C++20. In particular, Hyman Rosen -- an established senior member of Bloomberg's BDE team introduced what is now widely accepted as the five (at least theoretically) distinct possible semantics for any CCS: (1) "ignore", (2) "assume", (3) "check (always continue)", (4) "check (maybe continue)", and [hypothetical - not for C++20] (5) "check (always continue). These five semantics -- independent of any syntax -- would be explained in both p1332r0 and p1333r0, and the first four (for C++20) in p1429r0. 2018 - [November] A newly retrofitted BDE infrastructure -- instrumented with both 'bsls_assert' and 'bsls_review' (as appropriate) -- was rolled out to production with spectacular success -- most of the defects that were diagnosed were trivially fixed, but a few caught real bugs that could have potentially compromised reliability -- i.e., stability or, worse, correctness. 2018 - [November] Two new papers, p1333r0 and p1334r0 (Berne and Lakos), detailing the new semantics, the ability to assign them independently and directly on the command line, and a proposal to allow the semantics themselves to be added directly to individual CCSs, in lieu of the (late-binding) level, are submitted to the post San-Diego-meeting mailing. 2019 - [January] A composite paper, p1429r0, representing Bloomberg's best (minimal yet effective) recommendation for C++20, entitled "Contracts That Work" (Berne and Lakos) was submitted to the pre-meeting mailing for Kona. 2019 - [February] Bloomberg plans to present its position on contracts, beginning with a summary of this timeline of user experience, followed by a comprehensive presentation of the issues by Josh Berne, a progress update (p1488r0) on implementing p1429r0 using the GCC compiler by Andrew Sutton, a side-by-side comparison of using the status quo, p1290r1 (Garcia and Voutilainen) and p1432r0 (Berne & Lakos), and finally my ultimate proposal p1486r0 for a "United Amendment to Contract Facility for C++20" (Lakos).