The Two-Decade Quest: C++ Contracts

Great Founder Theory in C++

Document number: P3XXX

Date: 2025-12-18

Project: Programming Language C++, WG21

Reply-to: [Author]

The Two-Decade Quest: C++ Contracts Through the Lens of Great Founder Theory

Abstract

This paper analyzes the 21-year trajectory of C++ Contracts—from the first proposal in 2004 to adoption in C++26 (2025)—using Great Founder Theory (GFT) as an analytical framework. We examine how the feature was added to C++20 in 2018, dramatically modified, and then removed entirely in 2019, leading to the formation of a dedicated study group (SG21) and a complete redesign. We name the key individuals, corporations, and decisions that shaped this outcome, and use this historical analysis to infer conclusions about the effectiveness of the committee process. Finally, we propose structural reforms and consider whether an alternative governance model is necessary to serve the evolving needs of the C++ community.

1. Introduction

C++ Contracts—language support for specifying preconditions, postconditions, and assertions—represent one of the most prolonged and contentious features in C++ standardization history. First proposed in 2004, added to the C++20 working draft in 2018, removed in 2019 after a “heated discussion” in Cologne, and finally adopted for C++26 in February 2025, the feature’s tortuous journey illuminates fundamental tensions in language standardization.

As Herb Sutter declared in 2018:

“Contracts is the most impactful feature of C++20 so far, and arguably the most impactful feature we have added to C++ since C++11.”

Yet within a year, the feature was unanimously removed. The subsequent five-year redesign effort produced P2900, a 119-page proposal that generated sustained opposition even as it progressed toward adoption.

Great Founder Theory provides a framework for understanding institutional dynamics: how vision-driven leadership enables progress, how its absence creates dysfunction, and how “borrowed” versus “owned” power shapes outcomes. Applied to WG21, GFT illuminates why Contracts repeatedly failed despite widespread agreement on its value, and what structural changes might prevent similar failures.

2. Timeline: Four Phases of Contracts

2.1 Phase One: Early Proposals (2004-2016)

The Ottosen Era (2004-2006):

The first formal proposal for Design by Contract in C++ appeared in N1613 (2004) by Thorsten Ottosen, heavily influenced by the D programming language. The proposal introduced:

• precondition and postcondition blocks

• Class invariants

• Inline violation handling

This evolved through four revisions:

• N1669 (2004): Revision 1 (Ottosen)

• N1773 (2005): Revision 2 (Dave Abrahams, Lawrence Crowl, Ottosen, Jeremy Widman)

• N1866 (2005): Revision 3 (Crowl, Ottosen)

• N1962 (2006): Revision 4 (Crowl, Ottosen)

Key design changes across revisions:

• Keywords in/out replaced by precondition/postcondition

• Old-value syntax evolved: std::old(x) → __old(x) → oldof(x)

• “Importance ordering” (checking levels) added then removed

The Bloomberg BDE Foundation (2004-2014):

Parallel to committee work, John Lakos at Bloomberg developed a practical, library-based contract-checking facility called bsls_assert within Bloomberg’s BDE (Bloomberg Development Environment):

• 2004: First incarnation of bde_assert conceived by Lakos

• 2005: First production use outside infrastructure teams

• 2008: Major refactoring with fine-grained control

• 2012: Open-source release of BDE libraries incorporating bsls_assert

• 2013: First committee paper (N3604) by Lakos & Zakharov proposing standardization

Bloomberg’s experience would prove foundational. As documented in P1487:

“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 preconditions) are first presented outside of Bloomberg at ACCU’09.”

The Lakos-Myers Language Proposal (2014-2015):

• N4075 (2014): Final macro-based proposal—rejected at Rapperswil for heavy macro dependence

• N4135 (2014): First language-based proposal from Bloomberg (Lakos, Zakharov, Beels, Myers)

• N4378 (2015): “Language Support for Contract Assertions (Revision 10)” by Lakos, Myers, Zakharov, Beels

As P1487 notes:

“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.”

2.2 Phase Two: The Unified Proposal and C++20 Adoption (2016-2018)

The P0380 Merger:

In May 2016, a pivotal merger occurred. P0380R0 “A contract design” united two approaches:

• Microsoft’s static-analysis-focused declaration annotations (N4435, Walter Brown)

• Bloomberg’s runtime-checking and violation-handling experience (N4378)

Authors: Gabriel Dos Reis, J. Daniel Garcia, John Lakos, Alisdair Meredith, Nathan Myers, Bjarne Stroustrup

This collaboration represented an unusual alliance: Microsoft (Dos Reis), Academia (Garcia from UC3M), Bloomberg (Lakos, Myers, Meredith), and the language creator (Stroustrup).

P0542: The C++20 Contracts Proposal:

P0542 evolved through five revisions, culminating in P0542R5 (June 2018), which was adopted into the C++20 working draft. Key features:

int f(int x)
  [[expects: x > 0]]           // precondition
  [[ensures res: res > 0]]     // postcondition
{
  [[assert: x != 42]];         // assertion
  return x * 2;
}

Contract levels: default, audit, axiom Build modes: Determining which levels are checked Violation handler: Customizable response to failures

Implementation Progress:

GCC implemented the C++20 contracts proposal (P1680R0), providing the first compiler support.

2.3 Phase Three: The Cologne Crisis and Removal (2019)

The Kona Warning Signs (February 2019):

At the Kona meeting, significant concerns emerged about the design:

• Unchecked contracts were “assumed” by default, introducing undefined behavior

• The meaning of axiom was unclear

• No consensus existed among the original authors on how to fix these issues

The Cologne Debacle (July 2019):

As Timur Doumler reported:

“In Cologne, we then had over a dozen papers on the table in EWG, pointing out those and other issues, and suggesting different, mutually incompatible solutions.”

Key papers included:

• P1429 (Joshua Berne, John Lakos): “Contracts That Work”—redefining behavior in terms of named semantics

• P1607: “Minimizing contracts”—removing levels entirely, using literal semantics

The Last-Minute Change:

EWG approved P1607, a significant redesign that removed contract levels and build modes in favor of literal semantics. However, this late change:

“eroded trust in the proposed design and ultimately caused WG21 consensus on the entire feature to evaporate.” (P2899R1)

The Evening Session:

A special evening session convened with contract paper authors:

“In this meeting, we talked in great detail about different use cases of contracts, and learned that we don’t actually yet understand each other’s use cases well enough to be able to make any decision confidently.” (Timur Doumler)

Unanimous Removal:

P1823R0 proposed removing contracts from C++20, and the committee agreed unanimously. As the rationale document records:

“This late and massive change eroded trust in the proposed design and ultimately caused WG21 consensus on the entire feature to evaporate.”

2.4 Phase Four: SG21 and the MVP Redesign (2019-2025)

Formation of SG21:

Following the Cologne removal, SG21 (Contracts Study Group) was established:

• Chair: John Spicer (Edison Design Group)

• Co-chairs (later): Timur Doumler

• Mandate: Design a contracts facility that achieves consensus

The MVP Philosophy:

SG21 adopted a “Minimum Viable Product” approach, as explained in P2817:

“The goal for the Contracts MVP is to have a better status quo when contract ‘controls’ are discussed: the status quo that is not just nothing, but something of value, even if this value is small.”

This recognized that P0542 had been “too big to be added within a three- or even six-year time frame.”

Key Contributors to P2900:

The P2900 author list reflects years of collaborative work:

• Joshua Berne (Bloomberg)

• Timur Doumler (JetBrains, later independent)

• Andrzej Krzemieński (Poland NB)

• With: Gašper Ažman, Peter Bindels, Louis Dionne, Tom Honermann, Lori Hughes, John Lakos, Lisa Lippincott, Jens Maurer, Ryan McDougall, Jason Merrill, Oliver Rosten, Iain Sandoe, Ville Voutilainen

Design Evolution (2020-2024):

Competing Proposals:

Not everyone agreed with P2900’s direction:

• P2680 (Gabriel Dos Reis): “Contracts for C++: Prioritizing Safety”—proposed “strict” contracts with stronger UB protections

• P3285: Extension of P2680’s strict/relaxed model

• P3265: “Ship Contracts in a TS”—proposed deferring to a Technical Specification

• P3573: “Contract concerns”—raised late objections (Stroustrup among authors)

• P3829: “Contracts do not belong in the language” (Dos Reis, Voutilainen, Spicer, Garcia, Chisnall)

The Hagenberg Adoption (February 2025):

Despite sustained opposition, P2900R14 was adopted. As the rationale document notes:

“At the end of this session, EWG took a poll on whether, given the sustained opposition, the Contracts proposal should be withdrawn from consideration for C++26, and consensus was not to do so.”

Virtual functions were excluded, with work continuing on that extension.

3. Key Individuals and Their Roles

3.1 John Lakos (Bloomberg)

Lakos represents the deepest practical experience with contract-based programming at scale. His contributions span:

• 2001: Created Bloomberg’s BDE group

• 2004: Conceived bde_assert

• 2013-2015: Led committee proposals (N3604, N4075, N4135, N4378)

• 2016: Co-author of P0380 merger

• 2018-present: Continued advocacy through P1429, P1332, P2755

Lakos embodies the “narrow contracts” philosophy—that undefined behavior in interfaces is acceptable and even desirable when combined with defensive programming and configurable assertion checking.

3.2 Gabriel Dos Reis (Texas A&M → Microsoft)

Dos Reis brought academic rigor and corporate resources:

• 2015: N4435 “Proposing Contract Attributes” (Microsoft SAL experience)

• 2016: Co-led P0380 merger

• 2017-2018: Co-author of P0542

• 2022-present: P2680 “Prioritizing Safety,” advocating for stricter contracts

His P2680 represented a philosophical divergence from P2900, emphasizing static analysis and UB elimination over runtime checking flexibility.

3.3 Bjarne Stroustrup (Language Creator)

Stroustrup’s involvement in contracts has been consistent but constrained:

• 2016: Co-author of P0380

• 2017-2018: Co-author of P0542

• 2025: Co-author of P3573 “Contract concerns”

His late opposition (P3573) illustrates the limits of “borrowed power”—even the language creator cannot unilaterally shape outcomes when committee consensus has formed.

3.4 Joshua Berne (Bloomberg)

Berne emerged as a central figure in the post-2019 redesign:

• P1332R0 (2018): “Contract Checking in C++: A (long-term) Road Map”

• P1429 (2019): “Contracts That Work”

• P2751, P2811, P2877, P2932: Multiple foundational P2900 papers

• Lead author of P2900

His sustained effort over six years represents the “owned power” that ultimately drove standardization.

3.5 Timur Doumler (JetBrains → Independent)

Doumler brought communication skills and process leadership:

• SG21 co-chair

• CppCast co-host (community communication)

• P2885: “Requirements for a Contracts syntax”

• Co-author of P2900

• Author of explanatory materials (”Contracts for C++ explained in 5 minutes”)

3.6 John Spicer (Edison Design Group)

As SG21 chair, Spicer provided neutral leadership through contentious debates, leveraging his position as a compiler vendor representative with no direct stake in the design outcome.

4. Corporate Dynamics

4.1 Bloomberg’s Dominant Role

Bloomberg’s influence on contracts is unparalleled among corporations:

Human resources: Lakos, Berne, Meredith, Myers, Khlebnikov, Halpern, and others Practical experience: Decades of bsls_assert deployment across thousands of developers Philosophical foundation: The narrow-contracts/defensive-programming paradigm

This concentration created both benefits (deep practical knowledge) and concerns (single-company dominance of direction).

4.2 Microsoft’s Contribution and Divergence

Microsoft contributed through Dos Reis:

• SAL (Source Annotation Language) experience informed static-analysis aspects

• P2680 proposed alternative direction emphasizing safety over flexibility

The divergence between P2680 and P2900 illustrates how corporate priorities (Microsoft’s safety emphasis vs. Bloomberg’s flexibility emphasis) can create parallel tracks.

4.3 Limited Corporate Investment Elsewhere

Unlike coroutines (Microsoft), modules (Microsoft/Google), or executors (NVIDIA/Meta), contracts lacked broad corporate championship. This may explain the prolonged timeline—no company invested in implementations beyond GCC’s academic effort.

5. Great Founder Theory Analysis

5.1 The Missing Founder

Contracts’ history reveals a founder vacuum. Unlike features with clear technical champions (Gor Nishanov for coroutines, Eric Niebler for ranges), contracts had:

• Multiple co-equal authors: P0542 had six authors with different priorities

• Philosophical divisions: Runtime checking vs. static analysis, flexible vs. strict semantics

• No implementation authority: Bloomberg controlled BDE but not compilers; Microsoft had compilers but not committee consensus

In GFT terms, no individual possessed both the vision clarity to define the feature and the owned power (implementation control) to realize it.

5.2 The 2019 Collapse as Founder Vacuum Consequence

The Cologne collapse demonstrates what happens without authoritative technical leadership:

1. Multiple incompatible fixes: Over a dozen papers proposed different solutions

2. Last-minute direction change: P1607 adoption showed no stable design center

3. Trust erosion: Late changes “eroded trust in the proposed design”

4. Unanimous retreat: Removal was the only consensus achievable

Compare this to coroutines: when Google raised objections, Microsoft’s Gor Nishanov could defend and modify the design authoritatively because he controlled the implementation and understood every design tradeoff.

5.3 The Bloomberg Semi-Founder Model

Post-2019, Bloomberg’s team (Lakos, Berne) emerged as de facto founders:

• Deep domain expertise: Decades of practical experience

• Sustained commitment: Berne authored or co-authored dozens of papers over six years

• Implementation knowledge: BDE provided practical validation

However, they lacked:

• Compiler control: GCC/Clang implementations were separate efforts

• Formal authority: SG21 operated by consensus, not founder direction

This “semi-founder” model proved sufficient to reach adoption but created ongoing controversy (P3573, P3829 opposition).

5.4 Borrowed vs. Owned Power

The pattern suggests borrowed power enables blocking but owned power enables completion. Bloomberg’s team had enough owned power (sustained effort, practical experience) to complete P2900 despite borrowed power opposition.

6. Process Effectiveness Assessment

6.1 What Failed

The 2018 Premature Adoption:

P0542 was adopted without:

• Multiple production implementations

• Consensus among authors on core semantics

• Resolution of axiom/assume controversy

Evidence: The feature was removed less than a year after adoption.

The “Levels vs. Semantics” Design Gap:

The fundamental disagreement between “levels” (P0542) and “literal semantics” (P1429/P1607) was never resolved before adoption:

“The lack of consensus over a number of ‘controls’ (how continuation works, are levels enough or do we want ‘labels’ or ‘roles’ or ‘semantics’, when can contract conditions be ‘assumed’ by the compiler) meant that the entire P0542-contracts had to be removed.” (P2817)

The Late-Change Dynamic:

P1607’s adoption at the C++20 feature-freeze meeting demonstrated:

• Insufficient time for reflection

• Schedule pressure overriding quality

• “Last minute and massive change” destroying consensus

6.2 What Worked (Eventually)

The SG21 Process:

Post-2019, SG21 employed:

• Dedicated study group with neutral chair

• Extensive use case gathering before design

• MVP philosophy prioritizing consensus over completeness

• Multi-year timeline allowing iteration

The MVP Philosophy:

By explicitly accepting incompleteness, SG21 avoided the “everything at once” trap:

“By definition, an MVP cannot satisfy all known use cases but is designed to satisfy basic use cases from the start and simultaneously to allow satisfying other important use cases via future extensions.” (P2899R1)

Implementation-Informed Design:

GCC and Clang forks implemented P2900, providing feedback before final adoption (P3460R0).

6.3 Quantified Dysfunction

Contracts’ timeline exceeded even the notoriously troubled Concepts feature. The 2019 removal directly caused a six-year delay.

7. Structural Problems Identified

7.1 The Multi-Stakeholder Design Problem

Contracts attempted to satisfy fundamentally different use cases:

1. Runtime checking (Bloomberg philosophy): Configurable assertion checking, violation handlers

2. Static analysis (Microsoft philosophy): Compiler-verifiable properties, UB elimination

3. Optimization hints (assume semantics): Performance-oriented undefined behavior

4. Documentation (axiom philosophy): Human-readable interface contracts

No mechanism existed to prioritize among these or to explicitly exclude some for later.

7.2 The Consensus Trap

WG21’s consensus requirement created deadlock:

• Strong support for some contracts existed throughout

• Strong opposition to any particular design existed throughout

• Result: Years of churn with no progress

The 2019 evening session revealed:

“We don’t actually yet understand each other’s use cases well enough to be able to make any decision confidently.”

Understanding emerged only after the feature was removed.

7.3 The Schedule Pressure Problem

Both the 2018 adoption and 2019 removal were driven by schedule:

• 2018: “Add to C++20” pressure led to premature adoption

• 2019: Feature-freeze deadline forced decision without resolution

As P2899R1 notes regarding P1607:

“It is arguably a significant redesign, and the committee ultimately agreed that it was too late in the C++20 release cycle to approve such a redesign now.”

Schedule should serve design, not vice versa.

7.4 The Implementation Gap

Unlike coroutines (Microsoft had shipping implementation) or modules (Microsoft and Google had competing implementations), contracts had:

• One academic implementation (GCC)

• No production deployment of the standard design

• No “vote with your feet” user feedback

Bloomberg’s BDE experience validated library-based contracts, not the language-based design being standardized.

8. Proposed Reforms

8.1 Mandatory Design Authority Assignment

Problem addressed: Multi-stakeholder deadlock without authoritative resolution.

Proposal: When a study group is formed for a major feature, the convener should appoint a “Design Authority” (individual or small team of 2-3) with:

1. Final decision authority on design disputes within the study group

2. Responsibility to present unified recommendations to EWG

3. Accountability for implementation coordination

Rationale: The SG21 process worked better than ad hoc EWG debate, but still lacked authoritative resolution. A named Design Authority could have resolved the levels/semantics debate in 2018-2019.

8.2 Implementation Before Working Draft Inclusion

Problem addressed: Adopting untested designs.

Proposal: Before any feature enters the working draft:

1. At least one quality implementation must exist

2. The implementation must be publicly available for experimentation

3. At least one release cycle of user feedback must be gathered

P2900’s progression (GCC/Clang forks → implementation papers → adoption) demonstrates this works. Make it mandatory.

8.3 Explicit Use Case Prioritization

Problem addressed: Attempting to satisfy incompatible use cases simultaneously.

Proposal: Major features must include explicit use case prioritization:

1. Primary use cases: Must be fully satisfied

2. Secondary use cases: Should be accommodated

3. Deferred use cases: Explicitly excluded from initial design

4. Non-goals: Use cases the design explicitly does not support

SG21’s MVP philosophy implicitly did this. Make it explicit and mandatory.

8.4 Time-Bounded Study Group Authority

Problem addressed: Indefinite churn without resolution.

Proposal: Study groups receive a fixed mandate (e.g., 3 years) with:

1. Clear deliverables defined at creation

2. Mandatory progress reviews at 12-month intervals

3. Extension requires explicit committee vote

4. Dissolution if deliverables not achieved

This prevents features from languishing indefinitely while consuming committee resources.

8.5 Competing Proposal Process

Problem addressed: Late competing proposals disrupting consensus.

Proposal: Once a proposal reaches EWG review:

1. Competing proposals must be filed within 60 days

2. EWG explicitly votes to select a direction

3. Non-selected proposals may return only in the next release cycle

4. Late papers (after direction vote) require 2/3 supermajority to consider

This prevents the “dozen papers on the table” scenario that collapsed C++20 contracts.

9. Is the ISO Process Viable?

9.1 The Case for Reform Within ISO

Arguments:

1. SG21 succeeded eventually: The study group model produced P2900

2. MVP philosophy works: Explicit scoping achieved consensus

3. Implementation feedback helps: GCC/Clang forks informed design

4. ISO legitimacy matters: Standard status enables adoption

Assessment: The post-2019 process worked, albeit slowly. The problem was 2018-2019, not the ISO framework itself.

9.2 The Case for Alternative Governance

Arguments:

1. 21 years is unacceptable: Other languages (Rust, Go) ship features in months

2. Sustained opposition continues: P3573, P3829 show contracts remains contested even post-adoption

3. Volunteer burnout: Six years of Berne’s papers represents unsustainable individual effort

4. Corporate dominance: Bloomberg’s philosophy prevailed through attrition

Assessment: The current process can produce results but at costs (time, volunteer effort, acrimony) that may be unsustainable as feature complexity increases.

9.3 A Federated Model Alternative

We propose a federated governance model that separates experimentation from standardization:

Layer 1: Experimental Features (outside ISO)

• Managed by a C++ Evolution Foundation

• Six-month release cycles

• Features flagged as experimental/stable

• Compiler vendors opt-in to experimental features

• User feedback drives stability promotion

Layer 2: ISO Standardization

• Considers only “stable” features from Layer 1

• Three-year cycles maintained

• Provides legal/procurement guarantees

• Focus on wording and formal specification

Advantages:

1. Faster experimentation: New ideas ship in months, not decades

2. User feedback loop: Real deployment informs design

3. Reduced committee burden: ISO focuses on proven features

4. Volunteer sustainability: Shorter cycles reduce burnout

Contracts under this model:

• 2016-2017: P0380 design ships experimentally in one compiler

• 2017-2018: User feedback reveals axiom/assume problems

• 2018-2019: Redesign ships experimentally, iteration continues

• 2020: Stable design emerges from field experience

• 2023: ISO adopts proven design

Estimated time savings: 5-10 years vs. actual trajectory.

9.4 Comparison to Rust/TC39 Models

Rust:

• RFC process requires implementation before stabilization

• Edition mechanism allows breaking changes within compatibility guarantees

• Federated teams with clear authority domains

• Result: Major features (async/await, const generics) ship in 2-4 years

TC39 (JavaScript):

• Staged proposal process (0-4)

• Browser implementation required before Stage 4

• Six-month release cycles absorb incremental changes

• Result: Complex features (modules, async/await) ship in 3-5 years

C++ could adopt:

• Rust’s “implementation required” discipline

• TC39’s staged process with clear criteria

• Both models’ shorter iteration cycles

10. Conclusion

The 21-year journey of C++ Contracts reveals both the strengths and limitations of WG21’s processes:

Strengths demonstrated:

• Deep technical analysis

• Multiple implementation perspectives

• Eventually, consensus achievement

Limitations revealed:

• Inability to resolve multi-stakeholder disputes efficiently

• Schedule pressure corrupting design quality

• Volunteer effort unsustainability

• No mechanism for authoritative technical direction

The reforms proposed here—design authority assignment, implementation requirements, explicit use case prioritization, time-bounded mandates, and competing proposal discipline—could address observed dysfunction while preserving ISO standardization’s benefits.

The more fundamental question is whether C++ can afford another 21-year feature development cycle. Modern software development moves faster; languages that cannot evolve at comparable pace risk obsolescence regardless of technical merit.

Contracts will ship in C++26. The question is whether WG21 can learn from this experience to deliver future features in years rather than decades. The answer will determine whether C++ remains a viable choice for the next generation of systems software.

References

Committee Papers: Early Proposals

• N1613: Ottosen. “Proposal to add Design by Contract to C++” (2004)

• N1669, N1773, N1866, N1962: Contract Programming revisions (2004-2006)

• N3604: Lakos, Zakharov. “Centralized Defensive-Programming Support” (2013)

• N4075, N4135, N4378: Language-based contracts proposals (2014-2015)

Committee Papers: P0542 Era

• P0380: Dos Reis, Garcia, Lakos, Meredith, Myers, Stroustrup. “A contract design” (2016)

• P0542R5: “Support for contract based programming in C++” (2018)

• P1289R1: Garcia, Voutilainen. “Access control in contract conditions” (2018)

• P1323R2: Tong. “Contract postconditions and return type deduction” (2019)

Committee Papers: 2019 Crisis

• P1429: Berne, Lakos. “Contracts That Work” (2019)

• P1607: “Minimizing contracts” (2019)

• P1823R0: “Remove Contracts from C++20” (2019)

Committee Papers: P2900 Development

• P2388: Krzemieński, Ažman. “Minimum Contract Support” (2021)

• P2521: “Contract support — Working Paper” (multiple revisions)

• P2680: Dos Reis. “Contracts for C++: Prioritizing Safety” (2022)

• P2817: Krzemieński. “The idea behind the contracts MVP” (2023)

• P2885: Doumler et al. “Requirements for a Contracts syntax” (2023)

• P2899R1: “Contracts for C++ — Rationale” (2025)

• P2900R14: “Contracts for C++” (2025)

Committee Papers: Opposition

• P3173: Dos Reis. “P2900R6 May Be Minimal, but It Is Not Viable” (2024)

• P3265: Voutilainen. “Ship Contracts in a TS” (2024)

• P3285: “Contracts Protecting The Protector” (2024)

• P3362: Voutilainen. “Static analysis and ‘safety’ of Contracts” (2024)

• P3573: “Contract concerns” (2025)

• P3829: Chisnall, Spicer, Dos Reis, Voutilainen, Garcia. “Contracts do not belong in the language” (2025)

Trip Reports and Commentary

• Doumler, T. “Trip report: July 2019 ISO C++ committee meeting, Cologne” (2019)

• Sutter, H. “Trip report: February 2025 ISO C++ meeting, Hagenberg” (2025)

• Ballo, B. “Trip Report: C++ Standards Meeting in Cologne, July 2019”

Secondary Sources

• P1487: “Bloomberg and Contracts: A historical timeline” (2019)

• Bloomberg. “Contracts, Undefined Behavior, and Defensive Programming” (white paper)

• Lakos, J. “Large-Scale C++ Software Design” (1996)

• Burja, S. Great Founder Theory (2020)

---

The views expressed in this paper are those of the authors. We welcome comment, correction, and debate.