
                                                    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).
