The Evolution of std::filesystem Through WG21

Great Founder Theory in C++

Abstract

The std::filesystem library, standardized in C++17, represents one of the longest standardization journeys in WG21 history. Originating as Boost.Filesystem in 2003 and finally reaching the standard fourteen years later, this component illustrates both the strengths and pathologies of committee-driven standardization. This paper traces the timeline, identifies key individuals, and evaluates the outcome through Samo Burja’s Great Founder Theory framework.

---

1. Timeline

---

2. Key Individuals

Beman Dawes (1944–2020)

The founder figure. Co-founded Boost (1998), designed and implemented Boost.Filesystem, chaired LWG during C++98, founded LEWG (2013), served on WG21 Direction Group (2017). His filesystem library was described as “the most tortuous, lengthy, and difficult library to have ever been standardised.”

Dawes exhibited classic founder characteristics: he identified a gap (no portable filesystem abstraction), built the social technology (Boost peer review process), and shepherded the design through multiple revisions spanning nearly two decades. His death in December 2020 marked the end of living knowledge transfer for this component.

P.J. Plauger / Dinkumware

Provided the commercial implementation shipping with Visual Studio from 2012. This early adoption created implementation experience that validated the design before standardization, though it also locked in certain behaviors.

Billy O’Neal (Microsoft)

Key contributor to NB comment resolution, later provided the definitive criticism of the encoding model. His observation that vcpkg “completely ripped out use of std::filesystem” due to encoding problems exemplifies how implementation experience can contradict standardized design.

Daniel Krügler, Robert Stewart

Primary technical reviewers in the Filesystem Study Group, responsible for standardese corrections.

Nico Josuttis, Jamie Allsop

Authors of P0011R0 on relative paths, which “broke the logjam” on that long-standing issue and enabled lexically_relative() and weakly_canonical().

Tom Honermann

Chair of SG16 (Unicode study group), which now owns the encoding problems inherited from filesystem’s design decisions.

---

3. Institutional Actors

Companies

EntityRoleDinkumwareCommercial implementation (MSVC)MicrosoftMajor implementation vendor, eventual critic (vcpkg removal)Red Hat / GCCReference implementationLLVM / libc++Alternative implementation, exposed iterator conformance issuesApplelibc++ consumer, affected by iterator non-conformance

Study Groups

GroupFunctionSG3Filesystem Study Group (now dormant)SG16Unicode/text encoding, now owns path encoding issuesLWGLibrary Working Group, final wording reviewLEWGLibrary Evolution Working Group, design approval

---

4. The Encoding Problem: A Case Study in Social Technology Failure

The fundamental design flaw in std::filesystem::path is its assumption that char strings are in the “native narrow encoding.” This decision, reasonable in 2003 when Boost.Filesystem was designed, became catastrophic as the world moved toward UTF-8.

The Trap

Platformchar string behaviorPOSIXPass-through (typically UTF-8)WindowsConverted from Active Code Page to UTF-16ResultCode working on Linux produces mojibake on Windows

The string() Method Debacle

P2319 documents how path::string() is fundamentally broken:

• Returns a string in “native ordinary encoding”—incompatible with std::format, std::print, and iostreams

• Encoding affected by runtime settings

• Transcoding is lossy—characters without ACP representation cause exceptions or data loss

The u8path Deprecation Disaster

P0482R6 (char8_t) deprecated std::filesystem::u8path with the rationale that the path constructor should handle UTF-8 directly via char8_t. The aftermath:

• LWG 3840: Requests undeprecation—”no consensus” from LEWG (January 2024)

• P3364R0: Proposes removal from C++26

• Problem: No ergonomic way to construct path from UTF-8 char data without deprecated API or reinterpret_cast

Billy O’Neal’s assessment:

“Before P0482, we could just call std::u8path and it would do the right thing on both POSIX and Windows. After compilers started implementing ‘20, we have to make assumptions about the correct ‘internal’ std::path encoding because there is no longer a way to arrive to std::path with a char buffer that we know is UTF-8 encoded and get the correct results. It’s one of the reasons we completely ripped out use of std::filesystem on most platforms from vcpkg.”

---

5. GFT Analysis

The Founder Pattern

Beman Dawes exemplifies the Great Founder archetype. He:

1. Identified a coordination problem: Portable filesystem operations required standardization

2. Created social technology: The Boost peer review process provided validation infrastructure

3. Built the institution: Boost became the proving ground for standard library additions

4. Maintained living knowledge: His continued involvement ensured design coherence through multiple revisions

The Succession Crisis

Dawes’ death in December 2020 created a classic succession failure. The knowledge required to evolve std::filesystem coherently—the design rationale, the tradeoffs considered and rejected, the understanding of why particular decisions were made—was never fully transferred.

Evidence of dead knowledge:

• P2319: Must reverse-engineer why string() behaves as it does

• P1030 (path_view): Multiple design conflicts with unclear resolution paths

• LWG 3840: Committee cannot reach consensus on u8path undeprecation because the original deprecation rationale is contested

Bureaucratic Sclerosis

The fourteen-year standardization journey exhibits classic bureaucratic dysfunction:

PeriodDurationCause2006–20115 yearsLWG diverted to C++0x2011–20154 yearsTechnical Specification process2015–20172 yearsTS-to-standard integration

The process prioritized “not getting it wrong” over delivering value. By the time std::filesystem was standardized, the world had moved to UTF-8, but the encoding model reflected 2003 assumptions.

The Borrowed Power Problem

The committee structure distributes borrowed power (positions, voting rights) without corresponding owned power (expertise, implementation control). This creates pathological dynamics:

• Compiler vendors hold owned power: Microsoft, GCC, and Clang implementers can ignore or work around problematic specifications

• Committee members hold borrowed power: They can vote on designs but cannot compel implementations

• Result: vcpkg (owned by Microsoft) removes std::filesystem while the committee debates u8path undeprecation

Empire Dynamics: High/Mid Tension

The filesystem saga shows repeated High/Mid conflicts:

• SG3 (Mid) developed the TS, but plenary (High) controlled timing

• LEWG (Mid) rejected u8path undeprecation, but LWG (Mid) kept the issue open

• SG16 (Mid) identifies encoding problems, but resolution requires LEWG/LWG (High) consensus

The lack of clear authority means problems are identified but not resolved. P2319 has been in progress since 2021; path_view (P1030) since 2018.

The “Mostly Fine” Pattern

Common assessments of other C++ features—”ranges is mostly fine,” “modules are mostly fine,” “c++ is mostly fine”—reveals the institutional reality. The standard library is not broken, but it is also not healthy. Features ship with known deficiencies because:

1. Process momentum prevents reversal

2. Theoretical consistency overrides practical utility

3. Correction requires navigating the same bureaucracy that created the problem

For filesystem specifically:

• The encoding model is broken on Windows, but “mostly fine” on POSIX

• Path decomposition has quirks, but “mostly works”

• Iterator conformance varies by implementation, but “usually close enough”

---

6. Lessons for Institutional Analysis

What Worked

1. Founder-driven development: Dawes’ sustained involvement produced coherent design through multiple revisions

2. Implementation experience: Boost.Filesystem’s decade of production use validated the core abstraction

3. Commercial validation: Dinkumware shipping with MSVC created early adoption

4. Study group focus: SG3 provided dedicated attention during TS development

What Failed

1. Knowledge transfer: Dawes’ death left the design orphaned

2. Encoding assumptions: 2003 design decisions became liabilities by 2017

3. Correction mechanisms: No effective path to fix known problems post-standardization

4. Process overhead: Fourteen years from Boost release to C++17 standardization

The Counterfactual

Had filesystem shipped in C++11 with its 2006 design, the encoding problems would have been discovered earlier, with more time to correct course before the committee’s momentum made changes difficult. The five-year pause for C++0x work created the worst outcome: a design frozen in 2006 assumptions, shipped in 2017 with those assumptions already obsolete.

---

7. Current State and Trajectory

Active Issues

Prognosis

The filesystem component will likely persist in its current form, with incremental patches addressing the worst problems:

• P2845 (C++26): Fixes path formatting via std::format

• P2319: May eventually deprecate string() and add display_string()

• path_view: Unlikely before C++29, possibly never if P2645’s concerns prevail

The fundamental encoding model cannot be fixed without breaking backward compatibility—a price the committee has shown no willingness to pay. Projects requiring robust cross-platform path handling will continue using custom solutions or avoiding std::filesystem entirely.

---

8. Conclusion

The std::filesystem saga illustrates the core tension in committee standardization: the process optimizes for consensus and stability, not correctness or timeliness. Beman Dawes’ fourteen-year effort produced a workable abstraction, but the committee’s bureaucratic structure locked in pre-Unicode assumptions and created no effective mechanism for correction.

From a Great Founder Theory perspective, std::filesystem shows what happens when a functional institution (Boost under Dawes) hands off work to a dysfunctional one (WG21’s process-bound bureaucracy). The founder’s living knowledge was necessary but not sufficient; the succession to committee ownership destroyed the capacity for coherent evolution.

The current proposals (P2319, P1030) represent attempts to recover lost functionality through the same process that created the problems. Whether they succeed depends less on technical merit than on whether the committee can find new founders willing to shepherd these changes through the multi-year approval gauntlet.

---

References

WG21 Papers

• N1975 — Filesystem Library Proposal for TR2 (Revision 3), Beman Dawes, 2006

• N3239 — Filesystem Library Update for TR2, Beman Dawes, 2011

• N3505 — Filesystem Library Proposal (Revision 4), Beman Dawes, 2013

• P0218 — Adopt the File System TS for C++17, Beman Dawes, 2016

• P0482R6 — char8_t: A type for UTF-8 characters and strings, Tom Honermann, 2018

• P0492R2 — Filesystem NB Comments, Beman Dawes & others, 2017

• P1030 — std::filesystem::path_view, Niall Douglas, 2018–present

• P2319 — Prevent path presentation problems, Victor Zverovich, 2021–present

• P2645 — path_view: a design that took a wrong turn, Victor Zverovich, 2022

• P2845 — Formatting of std::filesystem::path, Victor Zverovich, 2023

• P3364R0 — Remove Deprecated u8path overloads From C++26, 2024

LWG Issues

• LWG 2935, 2936, 2937 — create_directory and path::compare semantics

• LWG 3480 — directory_iterator not C++20 range

• LWG 3840 — filesystem::u8path should be undeprecated

Other Sources

• Boost.Filesystem documentation and release history

• ISO/IEC TS 18822:2015

• vcpkg issue tracker and commit history

• isocpp.org memorial: “Remembering Beman Dawes”