C++26 Is Still a Draft: Separate Contracts Proposals From Releases
Discussion of the C++26 Draft International Standard ballot raises a practical question for software teams: what should change in a release plan today? Start by separating the standard’s recorded status, proposals about its contents, and the behavior of the compiler that actually builds your application. Those are three different pieces of evidence.
Read the recorded status before naming an outcome
As checked on October 26, 2026, ISO’s page for ISO/IEC DIS 14882 labels the document under development and records stage 40.60, close of voting. It identifies the document as a Draft International Standard intended to replace ISO/IEC 14882:2024. That page does not describe C++26 as a published International Standard.
ISO’s C++ draft record: status, stage and lifecycle
A status page and a proposal can also reflect different moments. Preserve the date and document revision when comparing them. Do not turn a proposal’s preferred next step into an announcement that the step has already happened, or treat a reported ballot outcome as proof that a particular language feature has already been removed.
What the October 23 papers actually request
P4388R0, Ship C++26, is dated October 23. Joshua Berne proposes retaining Contracts and describes conditional paths depending on whether the ballot meets approval criteria: publication without technical changes in one case, or resubmission with a specified defect-report change in the other. These are requests to the committee, rather than a record that either path has been adopted.
P4388R0: Ship C++26, dated October 23
P4433R0, Do not remove Contracts from C++26, carries the same date. Its authors explicitly say the approval result and national-body technical comments were not yet known when they wrote it. They ask WG21 to retain contract assertions and seek confirmation at the November meeting in Búzios. The paper therefore documents an advocated response, not a completed decision to change the language.
P4433R0: proposal to retain Contracts
Keep your production baseline explicit
For an application team, make a short record of the compiler version, selected language mode, standard-library version, target platforms and dependency requirements in the shipping build. Then identify which planned work actually depends on a C++26 facility. A project that does not use the disputed feature has a different immediate exposure from one whose public interfaces already depend on it.
For each dependency, write down the evidence you need before adoption: an accepted specification change, documented support in the intended toolchain, and a representative build and test result. A successful demonstration with one compiler does not answer whether your other target platforms or dependency combinations behave the same way.
Separate experiments from commitments
Keep a small feature experiment on a separate branch or build target. Save its compiler settings and expected behavior, and rerun it when the toolchain changes. This is a practical way to learn while preserving a reproducible production baseline; it is not a claim about which current compiler fully implements Contracts.
When updating a team, use precise language: a paper proposes an action; a recorded committee decision adopts one; a tested build demonstrates behavior in a specific environment. None of those statements substitutes for all the others. This article does not establish a final ballot tally, a new publication deadline, or an adopted decision removing Contracts. Track those outcomes through subsequent records before changing a commitment that depends on them.
