What Are C++ Core Language Defect Reports?

This article explores C++ Core Language Defect Reports (DRs), detailing their definition, necessity, and the procedural framework the ISO C++ committee employs to eliminate ambiguities and technical errors from the language specification. It examines the responsibilities of the Core Working Group (CWG) and explains the lifecycle of a defect from initial identification to retroactive standardization across compiler implementations.

Understanding Core Language Defect Reports

The ISO C++ standard is an extensive, highly technical document defining the syntax, constraints, and semantics of the C++ programming language. Given the immense complexity of C++, edge cases inevitably arise where the standard text is contradictory, underspecified, or inadvertently invalidates valid code.

When such an error or omission is identified in the core language—as opposed to the standard library—it is tracked as a Core Language Issue. When the committee formally agrees that the text fails to express the intended design or produces an unintended ambiguity, the issue is classified as a Defect Report (DR). A DR represents a formal acknowledgment that the published standard contains an error requiring correction.

The Role of the Core Working Group (CWG)

Within the ISO C++ committee (WG21), work is divided across various subgroups. The Core Working Group (CWG) is responsible for the core language specification (Clauses 4 through 15 of the ISO standard), distinct from the Library Working Group (LWG). The CWG evaluates reported issues, determines standardizing intent, and crafts precise mathematical and legal wording to rectify problems without breaking existing code.

The Process of Resolving Ambiguities

The ISO committee follows a systematic pipeline to process defects and clarify the language standard:

  1. Submission and Triage: Issues can be submitted by compiler implementers, committee members, or standard users. Each issue receives an issue number and an initial status in the CWG Issues List. It is reviewed to ensure it is within the CWG scope and not a new language feature request.
  2. Evaluation: The CWG analyzes the issue to determine its validity. If the standard already provides a definitive answer, the issue is categorized as NAD (Not A Defect). If the issue represents a legitimate gap or conflict, it moves to active status.
  3. Determining Intent: The committee evaluates how real-world compilers (such as GCC, Clang, and MSVC) currently handle the construct, investigates the original historical intent behind the language feature, and weighs the impact of various interpretations on backward compatibility and safety.
  4. Drafting Precise Wording: Once a consensus on intent is reached, dedicated wording experts author specific textual changes to the standard specification to remove ambiguity.
  5. Plenary Approval: The proposed resolution is brought before the full WG21 committee during a plenary vote. If passed, the issue achieves WP (Working Paper) status, indicating the changes are formally committed to the working draft of the upcoming standard.

Retroactive Nature of Defect Reports

Unlike new language features, which apply only to future standard releases, resolutions to Defect Reports are generally treated as retroactive. When the committee resolves an ambiguity through a DR, the resolution represents how the language was always intended to behave. Compiler vendors typically apply the resolution to all supported language modes (e.g., applying a fix resolved in C++23 retroactively to their C++14, C++17, and C++20 compilation modes). This retroactive application ensures unified compiler behavior and preserves predictable program semantics across evolving standard revisions.