The 17-Year Voyage: C++ Concepts

Great Founder Theory in C++

The 17-Year Voyage: C++ Concepts Through the Lens of Great Founder Theory

Abstract

This paper analyzes the trajectory of C++ Concepts from initial design (2003) through final standardization (C++20) using Great Founder Theory as an analytical framework. We examine why a feature considered essential by the language’s creator required 17 years and two complete redesigns to reach the standard. We name the key individuals, institutions, and decisions that shaped this outcome, and use this historical analysis to draw conclusions about the effectiveness of the ISO 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++ Concepts represent one of the most significant and troubled features in the language’s history. First proposed in 2003, rejected from C++11 in 2009, redesigned from scratch in 2011-2013, published as a Technical Specification in 2015, and finally merged into C++20 in 2017-2020—the feature’s 17-year journey offers a unique window into the institutional dynamics of WG21.

Great Founder Theory (GFT) provides a framework for understanding how institutions rise, stagnate, and evolve based on the presence or absence of founding vision, the distinction between “borrowed” and “owned” power, and the patterns of institutional succession. Applied to WG21, GFT illuminates why certain features succeed while others languish, why the committee struggles with coherent vision, and what structural changes might address observed dysfunction.

2. Timeline: Three Epochs of Concepts

2.1 Epoch One: C++0x Concepts (2003-2009)

Origins and Key Figures:

The formal effort to add concepts to C++ began with papers by Bjarne Stroustrup (AT&T, later Texas A&M, later Morgan Stanley) and Gabriel Dos Reis (Texas A&M, later Microsoft) in 2003:

• N1510: “Concepts - Design Choices for Template Argument Checking” (October 2003)

• N1522: “Concepts - Design Choices for Template Argument Checking” (October 2003)

Simultaneously, work at Indiana University led by Jeremy Siek (with Andrew Lumsdaine, Douglas Gregor, Jaakko Järvi, and others) developed an alternative approach based on Siek’s G language research.

The Indiana-Texas Schism:

By 2005, two distinct approaches had emerged:

1. The Texas Proposal (Stroustrup, Dos Reis): Focused on constraint checking with explicit concept maps

2. The Indiana Proposal (Siek, Gregor, Lumsdaine): Focused on more elaborate checking including definition checking

In October 2005, at the committee’s direction, these two groups were asked to merge their approaches. As Dave Abrahams (BoostPro Computing) later reflected:

“While we try assiduously to avoid design work in the committee (our charter is to ‘standardize existing practice’), I believe we slipped up this time. In October 2005, when the differing ideas of two groups working outside the committee seemed to be causing a serious and irreparable rift within the committee, we asked them to work together toward a compromise proposal. Instead of allowing everyone’s work to proceed apace, we asked the people who were making the most progress to stop, synchronize, and maintain synchronization despite their fundamental disagreements about what concepts should look like.”

The Forced Merger and Its Consequences:

The compromise design, implemented in ConceptGCC by Gregor, entered the C++0x working draft in September 2008. However, problems quickly emerged. As Stroustrup later characterized it:

“The C++0x concept design evolved into a monster of complexity. We had 130 ‘concepts’ in the library and 70+ pages to describe the language mechanisms. To compare, algebra has on the order of a dozen concepts, and the original C with Classes manual was less than 70 pages.”

Frankfurt 2009: The Removal:

At the July 2009 Frankfurt meeting, the committee voted to remove concepts from C++0x. Stroustrup’s assessment was blunt:

“That—in my opinion—is a major setback for C++, but not a disaster; and some alternatives were even worse.”

The removal reflected several factors:

1. Complexity: 40+ pages of standardese for the language feature alone

2. Implementation concerns: ConceptGCC was slow; no commercial implementation existed

3. Usability doubts: Late papers by Stroustrup (N2906) identified fundamental usability problems

4. Schedule pressure: C++0x was already years behind schedule

2.2 Epoch Two: Concepts Lite and the Palo Alto Report (2010-2017)

The Resurrection:

Work resumed outside the committee in 2010. A pivotal moment came in January 2012 when Alex Stepanov (father of the STL) convened a week-long workshop in Palo Alto, California. Participants included:

• Bjarne Stroustrup

• Andrew Sutton (Texas A&M, later University of Akron)

• Gabriel Dos Reis

• Sean Parent (Adobe)

• Paul McJones (Adobe)

• Andrew Lumsdaine

• Jon Kalb

• Dan Rose

The result was N3351, “A Concept Design for the STL,” known as the “Palo Alto Report.” This document represented a fundamental rethinking: rather than starting from language mechanisms, it began with user needs—specifically, what concepts would be required to constrain the STL algorithms.

Concepts Lite:

Building on the Palo Alto foundation, Sutton, Stroustrup, and Dos Reis developed what became known as “Concepts Lite” (N3701, June 2013). The key insight was radical simplification:

“First and foremost, we had to find a design that was about an order of magnitude simpler to implement and use. We must not simply recreate the mess that was the C++0x standard library ‘concepts’.”

The design focused exclusively on constraint checking (not definition checking), used predicates as the fundamental mechanism, and dramatically reduced implementation complexity and runtime cost. The “Lite” designation refers to these implementation characteristics, not to reduced expressiveness—the feature maintains full expressive power while being far simpler to implement and use than the C++0x design.

Implementation and Technical Specification:

Sutton implemented Concepts Lite in a branch of GCC. By 2014, a working implementation existed for experimentation. In August 2015, the Concepts TS (ISO/IEC TS 19217:2015) was published.

Toronto 2017: Merger into C++20:

At the Toronto meeting in July 2017, the committee voted to merge the Concepts TS into the C++20 working draft. However, the merger excluded the “natural syntax” (abbreviated function templates) due to unresolved controversy.

2.3 Epoch Three: Syntax Wars and Final Standardization (2017-2020)

The Terse Syntax Debate:

Even after merging concepts into C++20, controversy continued over syntax. Multiple competing proposals emerged:

• P0745: Herb Sutter’s “Concept-constrained type specifiers”

• P1079: Stroustrup’s “A minimal solution to the concepts syntax problems”

• P1141: “Yet another approach for constrained declarations” (authored by 12 committee members including Voutilainen, Koeppe, Sutton, Sutter, Dos Reis, Stroustrup, Merrill, Tong, Niebler, Carter, Honermann, and Keane)

The 12-author paper P1141 represented an attempt to broker consensus. As Herb Sutter reported from the 2018 Rapperswil meeting:

“Concepts as a language feature will definitely be in C++20. However, there is still a lot of controversy over a potential ‘terse syntax’. Over the last year, many people have tried (and failed) to find a solution that could gain consensus.”

Final Resolution:

The abbreviated function template syntax was eventually adopted, allowing:

void sort(Sortable auto& container);

C++20 was finalized in February 2020 and published in December 2020, with concepts as a headline feature.

3. Key Individuals and Their Roles

3.1 Bjarne Stroustrup (Language Creator, Texas A&M → Morgan Stanley)

Stroustrup has been the persistent champion of concepts since their inception. His role demonstrates both the power and limitations of “borrowed power” in GFT terms. As C++’s creator, Stroustrup commands enormous respect—but the committee structure means he cannot simply decree features into existence. He must persuade, compromise, and accept committee decisions he disagrees with.

Stroustrup’s 2018 paper “Remember the Vasa!” (P0977) represents a remarkable admission of institutional dysfunction:

“Many/most people in WG21 are working independently towards non-shared goals. Individually, many (most?) proposals make sense. Together they are insanity to the point of endangering the future of C++... We are on a path to disaster through enthusiasm and design-by-committee.”

3.2 Andrew Sutton (University of Akron)

Sutton was Stroustrup’s postdoc at Texas A&M for three years, working closely with Dos Reis and Stroustrup on concepts design and implementation. He was the primary implementer of both C++0x concepts (in ConceptGCC, continuing Gregor’s work) and Concepts Lite in GCC. His sustained implementation effort over nearly a decade represents the critical “owned power” that enabled standardization. Without a working implementation, concepts would have remained theoretical.

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

Dos Reis collaborated with Stroustrup from the earliest concepts papers and contributed to both the theoretical foundations and practical design. His move to Microsoft aligned corporate resources with standardization goals.

3.4 Douglas Gregor (Indiana → Apple)

Gregor led the ConceptGCC implementation for C++0x concepts. After the 2009 removal, he moved to Apple where he worked on modules for Clang/LLVM. His departure from active concepts work after Frankfurt illustrates how institutional failures can lose key talent.

3.5 Alex Stepanov (A9/Amazon)

Though not a regular WG21 participant, Stepanov’s convening of the 2012 Palo Alto workshop was pivotal. His prestige as STL creator gave the resulting design legitimacy and momentum. This represents borrowed power applied effectively—Stepanov’s reputation enabled a reset that committee processes alone could not achieve.

3.6 Herb Sutter (Microsoft, WG21 Convener 2002-2008, 2009-present)

As long-time convener, Sutter shapes committee process and consensus-building. His active participation in the syntax debates (P0745) and his downplaying of the 2009 removal (”Concepts would be great, but for most users, the presence or absence of concepts will make no difference”) illustrate the tension between managing expectations and acknowledging institutional failure.

4. Corporate Dynamics

4.1 The Role of Academia

Concepts’ history is unusual in C++ standardization for its heavy academic involvement:

• Indiana University: Siek, Gregor, Lumsdaine, Järvi

• Texas A&M: Stroustrup, Dos Reis, Sutton (as postdoc)

• University of Akron: Sutton (as faculty)

This academic concentration had both advantages (theoretical rigor, implementation effort not constrained by commercial priorities) and disadvantages (limited resources, vulnerability to personnel changes, weak committee presence compared to major corporations).

4.2 Corporate Non-Investment

Notably absent from concepts’ history is major corporate championship. No company invested significant resources in implementing or promoting concepts until after the Concepts TS was published. Compare this to:

• Coroutines: Microsoft implemented in MSVC from 2013, years before standardization

• Modules: Both Microsoft and Google invested heavily in competing implementations

• std::execution (P2300): NVIDIA and Meta drove development with libunifex

The lack of corporate champion helps explain concepts’ prolonged timeline. Academic implementers (Gregor, Sutton) had to balance concepts work against teaching, research, and career advancement.

4.3 Microsoft’s Late Arrival

Microsoft’s eventual support—through Dos Reis joining Microsoft and MSVC implementing concepts—came late in the process. Had Microsoft invested in concepts implementation in 2010-2013 as they did with coroutines, the timeline might have compressed significantly.

5. Great Founder Theory Analysis

5.1 The Founder Vacuum

C++ occupies an unusual position: its creator remains active, yet lacks formal authority. In GFT terms, Stroustrup holds enormous “borrowed power” (prestige, respect, historical authority) but limited “owned power” (no veto, no implementation team, no corporate resources to deploy).

This creates a founder vacuum despite the founder’s presence. Stroustrup can warn of disaster (”Remember the Vasa!”) but cannot prevent it. He can champion features (concepts) but cannot force their adoption. The committee can ignore or override him, as it did repeatedly during 2003-2009.

5.2 Institutional Sclerosis

The 17-year concepts timeline demonstrates institutional sclerosis—the inability to make timely decisions even when the need is widely acknowledged.

Evidence of sclerosis:

1. Forced compromise (2005): Rather than letting competing designs develop independently and selecting the better one, the committee demanded premature unification

2. Escalating complexity (2006-2009): The compromise design grew increasingly baroque as it tried to satisfy incompatible goals

3. Catastrophic failure (2009): Rather than course-correcting earlier, the committee waited until the feature was so broken that removal was the only option

4. Prolonged recovery (2009-2017): Eight years elapsed between removal and re-adoption, despite continuous work

5. Syntax gridlock (2017-2019): Even after adoption, syntax debates consumed additional years

5.3 The Palo Alto Exception

The Palo Alto workshop represents a successful end-run around institutional sclerosis. Key features:

1. External venue: Held outside WG21’s formal structure

2. Curated participants: Stepanov invited specific experts rather than opening to all committee members

3. User focus: Started from “what do users need?” rather than “what can we specify?”

4. Founder authority: Stepanov’s prestige enabled authoritative direction-setting

5. Documented output: N3351 provided a concrete foundation for subsequent work

This pattern—external workshop, curated experts, clear founding authority, user focus—offers a template for escaping institutional gridlock.

5.4 Borrowed vs. Owned Power in Standardization

The concepts history illustrates GFT’s distinction between borrowed and owned power:

Borrowed power (prestige, authority, formal position):

• Stroustrup’s stature as language creator

• Stepanov’s reputation as STL author

• Committee chair authority to schedule discussions

• ISO imprimatur on published standards

Owned power (resources, implementation, deployment):

• Sutton’s GCC implementation

• Compiler vendors’ willingness to ship

• User adoption creating upgrade pressure

• Corporate resources funding sustained work

Concepts succeeded only when owned power (working implementation, user demand) aligned with borrowed power (committee votes, formal approval). The 2009 failure occurred because borrowed power (committee draft inclusion) lacked corresponding owned power (commercial implementation, proven usability).

6. Process Effectiveness Assessment

6.1 What Worked

Technical Specification process: The Concepts TS provided a “beta test” vehicle allowing implementation and user feedback before final standardization. This represented genuine process learning from the C++0x disaster.

Radical simplification: The willingness to discard C++0x concepts entirely and start fresh (the simplified concepts design, often called “Concepts Lite”) demonstrates that the committee can abandon failed approaches—eventually.

Multi-author consensus papers: P1141’s 12-author list showed that consensus-building across factions is possible when participants are motivated.

6.2 What Failed

Forced premature consensus (2005): The committee’s intervention to merge Indiana and Texas approaches created a design satisfying no one.

Insufficient implementation requirements: No commercial implementation existed before the 2008 working draft inclusion. The “Don’t standardize without commercial implementation” / “Major implementers do not implement without a standard” dilemma was never resolved.

Prolonged syntax debates: Years of committee time consumed debating syntax details that, in retrospect, mattered far less than getting concepts shipped.

Resource asymmetry: Academic champions (Sutton, Gregor) competed against corporate-backed proposals (coroutines, modules) with vastly fewer resources.

6.3 Quantified Dysfunction

The data suggests corporate championship correlates strongly with faster standardization. Concepts’ academic stewardship, while producing high-quality design, lacked the resources and political weight to drive rapid adoption.

7. Structural Problems Identified

7.1 Absence of Coherent Vision

Stroustrup’s “Vasa” paper identifies the core problem:

“Many/most people in WG21 are working independently towards non-shared goals.”

WG21 lacks a mechanism for establishing and enforcing coherent direction. The “Direction Group” (P0939) attempts to provide this but has no binding authority. Features advance or stall based on local consensus in subgroups, not global coherence.

7.2 Resource Asymmetry

Committee participation requires significant resources:

• Three week-long meetings per year (travel, lodging, opportunity cost)

• Continuous engagement with email reflectors

• Implementation effort for new features

• Paper preparation and revision

Corporations can fund dedicated employees for this work. Academics have teaching and research obligations. Independent contributors face severe disadvantages.

The Standard C++ Foundation’s financial assistance policy acknowledges this problem but provides only modest support for travel and hosting. It does not address the fundamental asymmetry.

7.3 Volunteer Burnout

Key individuals bear extraordinary burdens. Andrew Sutton maintained the GCC concepts implementation largely alone for years while holding academic positions. Oliver Kowalke has maintained Boost.Context, Boost.Coroutine, and Boost.Fiber while championing fiber standardization (P0876) through 19+ revisions over a decade—still not standardized.

The committee depends on sustained volunteer effort but provides no institutional support for sustainability.

7.4 Consensus Gridlock

WG21’s consensus-based process can produce gridlock when:

• Multiple valid approaches exist (concepts syntax, executors design)

• Participants have strong preferences

• No mechanism exists to force resolution

• Delay is the path of least resistance

The result is prolonged debates that exhaust participants without producing decisions.

7.5 Accretion Without Pruning

C++ grows monotonically. Features are added but rarely removed. The “Vasa” paper warns this pattern risks capsizing the language:

“We should not spend most of our time creating increasingly complicated facilities for experts, such as ourselves. We need a reasonably coherent language that can be used by ‘ordinary programmers’ whose main concern is to ship great applications on time.”

No mechanism exists to retire failed features, simplify over-complicated ones, or maintain coherent minimalism.

8. Proposed Reforms

8.1 Establish a Technical Direction Council

Problem addressed: Absence of coherent vision.

Proposal: Create a small (5-7 person) Technical Direction Council with authority to:

1. Set multi-year technical priorities

2. Declare proposals “in scope” or “out of scope” for each release cycle

3. Resolve gridlocked debates with binding decisions

4. Reject proposals that would add complexity without commensurate value

Composition: Selected by election among national bodies, with term limits. Must include the language creator (while active) and at least one representative from each major compiler vendor.

Precedent: Rust’s Leadership Council, Python’s former BDFL model.

8.2 Implement Mandatory Implementation Requirements

Problem addressed: Standardizing untested features.

Proposal: Before any feature enters a Committee Draft:

1. At least one production-quality implementation must exist

2. Implementation must be publicly available for user experimentation

3. Documented user experience must be presented

The Concepts TS process partially achieved this. Make it mandatory.

8.3 Create Funded Fellowships for Key Contributors

Problem addressed: Resource asymmetry, volunteer burnout.

Proposal: The Standard C++ Foundation should establish 3-5 year fellowships for individuals maintaining critical standardization efforts without corporate backing. Stipend equivalent to senior engineer salary.

Selection: Nominated by WG21 officers, approved by Foundation board.

Examples of candidates: Maintainers of Boost libraries feeding standardization, implementers of reference implementations for TS features, authors of major proposals without corporate affiliation.

8.4 Institute Time-Bounded Decision Requirements

Problem addressed: Consensus gridlock.

Proposal: After a proposal has been discussed at N meetings (suggest N=4) without resolution, the convener must:

1. Call for a binding vote

2. Declare the proposal deferred for 2 releases (if vote fails)

3. Or declare the proposal split (if multiple approaches have support)

This forces resolution rather than indefinite debate.

8.5 Establish a Simplification Study Group

Problem addressed: Accretion without pruning.

Proposal: Create a study group (SG-S) specifically tasked with:

1. Identifying features that could be deprecated

2. Proposing simplifications to overly complex features

3. Reviewing new proposals for simplification opportunities

4. Maintaining a “complexity budget” for each release

Composition: Must include educators and representatives of “ordinary programmers,” not just language lawyers.

9. Is the ISO Process Viable?

9.1 The Case for Reform Within ISO

Arguments:

1. Legitimacy: ISO standard status provides legal and procurement advantages

2. Inertia: Billions of lines of C++ code exist; abandoning ISO continuity creates chaos

3. Expertise: WG21’s ~200 participants represent irreplaceable knowledge

4. Recent improvements: Technical Specifications, Study Groups, and increased teleconferences show adaptability

Assessment: The reforms proposed in Section 8 could be implemented within ISO’s framework. No fundamental conflict exists between ISO processes and effective governance.

9.2 The Case for Alternative Governance

Arguments:

1. Speed: Rust ships releases every six weeks; C++ every three years. Modern software development cannot wait.

2. Coherence: Languages with technical leadership (Rust’s teams, Go’s core team, Python’s former BDFL) maintain coherent vision more effectively.

3. Inclusion: ISO’s geographic and corporate structure privileges certain participants over others.

4. Experimentation: ISO’s “standardize existing practice” mandate discourages innovation.

Assessment: These concerns are real but addressable within ISO. The fundamental problem is not ISO’s framework but WG21’s specific practices.

9.3 A Hybrid Model

We propose maintaining ISO standardization for major releases while creating a parallel “C++ Evolution” process for rapid experimentation:

C++ Evolution (outside ISO):

• Managed by Standard C++ Foundation

• Six-month “evolution releases” containing experimental features

• Features flagged with stability levels (experimental, beta, stable)

• Reference implementation required for inclusion

• Compiler vendors opt-in to supporting evolution features

ISO C++ Standard (within ISO):

• Three-year release cycle maintained

• Features promoted from “stable” evolution status

• Formal standardization provides legal/procurement guarantees

• Maintains backward compatibility commitments

Advantages:

• Experimentation without destabilizing production code

• Faster feedback loops for new features

• ISO standardization only for proven designs

• Reduces pressure to prematurely standardize

Precedent: TC39 (JavaScript) operates a similar staged proposal process, with browsers implementing features before formal standardization.

10. Conclusion

The 17-year voyage of C++ Concepts illuminates fundamental tensions in language standardization:

1. Vision vs. consensus: Coherent design requires direction; committee processes diffuse it

2. Experimentation vs. stability: Users need stable standards; designers need freedom to experiment

3. Resources vs. openness: Effective participation requires resources; open processes disadvantage the under-resourced

4. Speed vs. rigor: Markets demand rapid evolution; standards require careful deliberation

Concepts ultimately succeeded, delivering a valuable feature that will benefit C++ programmers for decades. But the cost—17 years, two complete redesigns, enormous volunteer effort, deferred improvements to other features—suggests the process is straining under modern demands.

The reforms proposed here—a Technical Direction Council, mandatory implementation requirements, funded fellowships, time-bounded decisions, and a simplification focus—could address observed dysfunction while preserving ISO standardization’s legitimacy. The hybrid model offers a path to faster experimentation without abandoning stability.

Whether WG21 can implement such reforms depends on whether participants recognize the depth of the problem. Stroustrup’s “Vasa” warning remains apt:

“We are on the path to something that could destroy C++. We must get off that path!”

Concepts’ successful completion proves the committee can deliver transformative features. The challenge is whether it can do so without requiring two decades and herculean volunteer sacrifice for each one.

References

Committee Papers

• N1510, N1522: Stroustrup, Dos Reis. Concepts - Design Choices for Template Argument Checking (2003)

• N3351: Stroustrup, Sutton (eds). A Concept Design for the STL (2012)

• N3701: Sutton, Stroustrup, Dos Reis. Concepts Lite (2013) [Note: The “Lite” designation refers to implementation complexity and runtime cost, not expressiveness]

• ISO/IEC TS 19217:2015: C++ Extensions for Concepts

• P0977R0: Stroustrup. Remember the Vasa! (2018)

• P0939: Dawes, Hinnant, Stroustrup, Vandevoorde, Wong. Direction for ISO C++ (2018)

• P1141R0: Voutilainen et al. Yet another approach for constrained declarations (2018)

• P1079: Stroustrup. A minimal solution to the concepts syntax problems (2018)

Secondary Sources

• Siek, J. “The C++0x ‘Concepts’ Effort.” Generic and Indexed Programming, LNCS 7470 (2012)

• Stroustrup, B. “No ‘Concepts’ in C++0x.” ACCU Overload 92 (2009)

• Sutton, A. “Introducing Concepts.” ACCU Overload 129 (2015)

• Gregor, D. et al. “Concepts: Linguistic Support for Generic Programming in C++.” OOPSLA’06 (2006)

• Burja, S. Great Founder Theory (2020)

Trip Reports and Commentary

• Sutter, H. Trip reports: Toronto (2017), Rapperswil (2018)

• JetBrains CLion Blog: ISO C++ Committee trip reports (2018)

• The Register: “What’s all the C Plus Fuss?” Interview with Stroustrup (2018)

---

Terminology Note

“Concepts Lite”: This paper uses the term “Concepts Lite” (from N3701) to refer to the simplified concepts design that entered C++20. The “Lite” designation refers to reduced implementation complexity and runtime cost compared to the C++0x concepts design, not to reduced expressiveness. The feature maintains full expressive power while being far simpler to implement and use. Some authors prefer alternative terminology to avoid the potential misinterpretation that “Lite” implies reduced capability.

---

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