claude-news
newsLobsters·27 Oct 2026·train-it.eu via fanf

The result of the C++26 DIS ballot

C++26 failed its DIS ballot, the first C++ draft ever to do so, delaying reflection, std::execution, hardening and contracts.

Depth 3/5Score 3.63

Extract

C++26 failed its DIS ballot. As far as I know, it is the first C++ draft to fail one. Robert Seacord, the convenor of the C committee, wrote that he doesn’t think any language standard from SC22 has ever failed its ballot before, and Daveed Vandevoorde, a member of the WG21 Direction Group (P5000R1), wrote that no earlier C++ draft got even a single vote against. So reflection, std::execution, library hardening, and contracts are all in a draft that ISO hasn’t approved, and nobody knows yet how long the delay will be. The ballot closed on 23 October 2026, and Robert Seacord, the convenor of the C committee, posted the result on LinkedIn the next day: Where I stand# I kept this series neutral while the vote was open and didn’t want to push anyone toward either side. The vote is over, so I can say where I stand. I love contracts as an idea, and I have missed them since they were removed from C++20. I have always cared about API design, about libraries, good interfaces, and frameworks, and that is also why I am in LEWG. My reasons for liking contracts come from that experience. Checking is one benefit, and a good one: the program can verify its own assumptions. The second axis, which I care about just as much, is documentation. A precondition or a postcondition in the signature records the intent of the API designer, so users know what to expect and how to use the function, and a documentation system such as Doxygen or cppreference.com can show it right there. A comment can say the same thing, but nothing keeps it true. It can drift away from the code without anyone noticing. A contract is part of the code. The compiler checks it together with the function, and when the checks are enabled, a violation fails loudly, so this documentation can’t quietly go stale. Concepts already give us both for the types a function accepts, at compile time. Contracts are the part that is still missing, the one that does the same for the values at run time. I would love to see contracts in the standard, and it is a pity they didn’t make it this time. My preference is to keep them. If the design comes out better because of this, that is a good result too. This isn’t an abstract question for me. I have started teaching C++26 contracts in my workshops, and mp-units uses the C++26 version. The numbers# Part 2 explained the two conditions a DIS has to meet. The draft missed both of them: ConditionRequirementResultVotes in favor, from the voting (P-)membersat least two-thirds12 of …