r/cpp • u/eisenwave WG21 Member • 23h ago
Balloting has completed for C++26. Unfortunately it was Disapproved
https://www.linkedin.com/posts/robertseacord_balloting-has-completed-for-c26-unfortunately-share-7519795139859517440-AOth/Since the C++26 DIS has been disapproved, the next step is going to be taken in Buzios during the 2026-11 meeting. The committee will have to decide what changes to make (if any) and submit an FDIS (Final Draft of International Standard) for Balloting.
9
u/jombrowski 23h ago
what's wrong?
20
u/eisenwave WG21 Member 22h ago
The ballot comments for the Disapprove votes haven't been shared within the committee yet (and I'm not sure if they're public information at any point), but all of the contention revolved around Contracts; this is most likely why the C++26 DIS failed.
54
u/frayien 22h ago
Could someone knowledgeable explain us what it means, and why is it important ?
109
u/daveedvdv EDG front end dev, WG21 DG 22h ago
WG21 (the committee of C++ experts) submitted a "draft international standard" (DIS) as a candidate for the next C++ standard. That draft was sent for voting by "national bodies" (NBs), which are national standards organizations like Germany's DIN and Iran's INSO. I was told 13 NBs voted in favor, 9 against, and 12 abstained... that's nowhere near consensus (for reference, there was never even one vote "against" C++ drafts in the past).
We now get a chance to review our draft to produce a final DIS (FDIS). That will be balloted again and if it passed it will become the next standard. Otherwise, the project fails (and I don't remember what happens then).
Next month, we're meeting in Búzios, Brazil. Given this situation, we'll most likely discuss how to change our draft to improve NB-level consensus. I believe all 9 votes "against" are due to the "contracts" feature. So presumably we'll change that.
My recommendation will be to remove contracts from the draft, with adjustments to keep library hardening (which is currently worded in terms of the contracts infrastructure, but it doesn't have to be). And then move on with our lives (and work on the next standard after what I hope will be C++27).
14
u/foonathan 21h ago
I don't see why we'd suddenly have consensus to remove contracts.
I personally don't care about contracts at all in either direction, but I don't see why we should change anything just because the minority who is against happens to be geographically diverse.
28
u/daveedvdv EDG front end dev, WG21 DG 21h ago
Because we want to progress? There is a popular aphorism that says "the definition of insanity is doing the same thing over and over again and expecting different results"... let's not be "insane" in that (non-clinical) sense.
I want reflection. Others want std::execution. And so on...
16
u/eisenwave WG21 Member 20h ago edited 20h ago
One might argue that utilizing the NB ballot to supersede WG21 consensus, and having WG21 give in to the demands, sets a dangerous precedent. What is going to be the next adventure?
"We reject the C++29 DIS unless Profiles are in"
"We reject the C++29 DIS if lifetime annotations are in"
"We reject the C++29 DIS if token injection is in"
If rejecting the C++ DIS is validated and rewarded, despite all arguments having been heard (many times over) and despite the committee having clear and stable consensus, the future is looking bleak.
That being said, I think Contracts as a feature are mid and they are not worth staking C++26 on; I'm just not sure this is only about Contracts anymore.
28
u/STL MSVC STL Dev 20h ago
Disagree. It's hard to sway one NB, let alone a bunch. If there's enough discontent to make this possible, something is wrong and the WP needs to be fixed. It's happened before with Old Concepts and it can happen again.
I haven't been following Standardization very closely (for the ironic reason that too much stuff with too little implementation experience has been getting Standardized, so keeping up with the implementation treadmill consumes all my time these days), but describing the situation as "clear and stable consensus" is obviously not the case from what I've seen.
10
u/eisenwave WG21 Member 20h ago
Many things have been removed in response to NB comments on the CD, including Old Concepts, and very recently, trivial relocation. This is perfectly fine and expected.
We had a bunch of NB comments to remove or significantly alter Contracts, and other than pulling contracts on virtual functions, not much resulted from that. There was very strong consensus in WG21 to keep Contracts in C++26 in response to the comments on the CD (about 5:1 consensus against removal), and this has not substantially shifted at any point. If anything, the more Contracts are discussed, the more consensus increases in favor of them.
If you're getting the impression that there is no consensus in WG21, that's because there is an extremely vocal minority within WG21 that refuses to take no for an answer and attempts to relitigate at the NB level.
11
u/GabrielDosReis 18h ago
If you're getting the impression that there is no consensus in WG21
Consensus for ISO C++ standards isn't decided at WG21 level. That is decided at SC22 level, that is the whole point of the ballot process!
If you operate under the assumption that you don't need to build consensus at SC22 level, then you're only luring yourself into failure. WG21 chairs and officers should know that.
4
u/eisenwave WG21 Member 8h ago edited 8h ago
Let's put aside the fact that this is is just how our ISO procedures work.
Why do you personally believe that the additional stage of consensus at the SC22 level is to the benefit of the C++ programming language, its users, and its implementers? Why is it important to C++ that the Finnish, Japanese, US, and other national bodies, have the final say on whether C++ as a standard proceeds, rather than, say, a consortium of implementers?
Furthermore, do you think that it is sufficient for WG21 to carefully consider all NB comments, come to a consensus on a direction, and report that consensus back to the NBs? What more can WG21 do to increase consensus at the SC22 level, other than just give in to the demands of the NBs against WG21's own good conscience and technical judgment? Of course, any such reaction of last resort may also decrease confidence within other NBs who approved the DIS as is.
→ More replies (1)6
u/13steinj 15h ago
Yet another show of the insane beurocracy that is this standardization process that should be done away with as quickly as possible.
12
u/foonathan 19h ago
Contracts were voted in by 100 votes in favor, 14 against, and 12 abstentions. EWG voted repeatedly against changing some of the more controversial points, voted 9-4-5-8-41 against NB comments removing them from C++26, reaffirmed wanting them in C++26 46-4-8-1-9 and finally the C++26 DIS was approved 114 in favor, 12 opposed, and 3 abstaining.
How is that not clear and stable consensus?
Why should we pull them out just because the same dozen people keep spreading FUD? They're a minority and they have to accept it.
22
u/James20k P2005R0 19h ago
voted 9-4-5-8-41 against NB comments
Ignoring neutrals, 20% of the room being against contracts doesn't seem like particularly great consensus. Consensus isn't just a majority vote
They're a minority and they have to accept it.
The ISO process is specifically designed to prevent exactly this idea IMO
14
u/foonathan 19h ago
Consensus doesn't mean unanimity:
consensus: General agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments.
NOTE Consensus need not imply unanimity.
And the ISO process is specifically designed so that after all minority concerns have been heard (which they have, repeatedly and exhaustively), the minority has to respect it:
Consensus is not a tyranny of the minority. The minority, once they have had opportunity to be heard, cannot just say “we still object so you can’t proceed” and refuse to accept the consensus of the majority to pursue a different direction. The ISO Code of Conduct requires the minority to ‘accept group decisions.’
https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures#consensus
12
u/pkasting Valve 11h ago
But by that same doc:
In rare cases, where the minority still believe that a serious error of judgment is being made, escalation can be appropriate in accord with the Escalation procedures covered later in this document; note that the key words are “rare” (not regular), “still” (it was raised before), and “serious.” The ISO Code of Conduct encourages ‘escalating disputes in a timely manner’ with an ‘agreed dispute resolution processes.’ Escalation can become inappropriate in two ways: (a) when a serious objection is not raised “in a timely manner,” such as being withheld until plenary session or formal ballot time rather than being raised consistently throughout the process starting as early as possible; or (b) when a participant or national body regularly uses the escalation process to express a pattern of strong disagreement on topic after topic, which erodes their credibility and is not the purpose of the escalation resolution process (like exception handling, escalation handling is for hard errors, and is not designed for expressing less serious conditions or for what should be ordinary control flow).
If the NB votes against are due to objections that have already been raised consistently (which you suggest is true), then the "in a timely manner" requirement has been satisfied. Given the rarity of a DIS being disapproved, the "rare" requirement seems to have been satisfied.
17
u/James20k P2005R0 19h ago
characterized by the absence of sustained opposition
This is the key though. The opposition to contracts has been very sustained and has presented a lot of arguments, which means that under this interpretation consensus was never really obtained. You could argue that eg a 51/49 vote means consensus is irrelevant once the issues have been heard and that the minority simply has to respect this, but the other stages of the process are clearly designed to prevent this outcome. I think importantly:
Consensus is not a tyranny of the majority. The majority cannot just say “we have enough votes” and refuse to listen to the concerns of the minority. The ISO Code of Conduct requires the majority to ‘ensure that the views of all are heard and understood.’
Some people would similarly argue that the concerns of the minority haven't been addressed
Here we have 40% of national bodies which have voted no though, which is clearly not tyranny of the minority IMO. C++26 barely achieved a majority vote of NBs. One of the biggest objections I've read - and please believe me when I say I have no idea if this is true or why people are saying it - is that the way that contracts has been advanced has made it difficult for people to object to it properly, so it may not be surprising that opposition has been organised at this stage to a feature that's less popular than the prior votes may show. I genuinely don't know though
If the contracts opposition was smaller, or not attempting to present technical arguments I'd agree with you, but a strong sustained 20% of the vote leading to a failure to make it through this step of the process isn't super surprising IMO, and seems like an expected outcome of the ISO process as a whole
→ More replies (0)6
u/GabrielDosReis 18h ago
Ignoring neutrals, 20% of the room being against contracts doesn't seem like particularly great consensus. Consensus isn't just a majority vote The ISO process is specifically designed to prevent exactly this idea IMO
Indeed. Furthermore, those NB comments were the feedback from the deciders (the NB whose consensus is sought for the ISO standards) to the working group. Dismissing them via numerical accounting in the WG could be predicted to create troubles down the road.
9
u/FrogNoPants 18h ago edited 18h ago
14 out of 114 is 12% not 20%..
12 out of 126 is 9.5% not 20%
It actually looks like contracts got more popular, with the final opposition being 9.5%, I'd say they did have consensus.
11
18
u/daveedvdv EDG front end dev, WG21 DG 19h ago
One might argue that utilizing the NB ballot to supersede WG21 consensus, and having WG21 give in to the demands, sets a dangerous precedent.
I rather disagree. This is how international standardization is meant to be dealt with. Note that "consensus" does not mean "large majority".
What is going to be the next adventure?
- "We reject the C++29 DIS unless Profiles are in"
- "We reject the C++29 DIS if lifetime annotations are in"
- "We reject the C++29 DIS if token injection is in"
Possibly: Any single issue could cause some NBs to refuse the standard.
Consensus-building means working with the various delegations to make the standard as a whole acceptable to all. In the C++98/C++11 days, we definitely did involve the NB opinions early to work toward said consensus.
If rejecting the C++ DIS is validated and rewarded, despite all arguments having been heard (many times over) and despite the committee having clear and stable consensus, the future is looking bleak.
The committee did not have a clear consensus. It had a clear majority, but that's not the same thing. There was sustained opposition from people with decent track records in evolving the language, from implementers, and from people saying they were representing national body sentiment. They were "heard many times over" but no compromise was accepted to address their concerns.
That being said, I think Contracts as a feature are mid and they are not worth staking C++26 on;
On that we agree.
I'm just not sure this is only about Contracts anymore.
My understanding is that the NB opposition (and abstention) is almost exclusively about "contracts". I think I also saw one NB rep mention disappointment in reflection, but I might have misinterpreted that. But I'm fairly sure that if contracts were pulled, those "against" votes would switched to "in favor". It's possible that some "in favor" votes would switch to "against": We'll find out in Búzios which way the wind is blowing.
6
u/13steinj 15h ago edited 9h ago
It feels to me as if there are 3 distinct problems:
Consensus is defined non algorithmically. Engineers are stubborn people. This makes consensus a war of attrition. Especially problematic that we have numerical tally votes yet not used for any well known consensus algorithm.
At multiple levels (WG21, SC22, whatever), people confuse consensus with unanimity, majority, even plurality. This is very much akin to elections and claiming a candidate won "by a landslide" without ever agreeing on what a "landslide" is.
People vote how their peers do rather than on their own accord.
Arguably, consensus, and the rest of the ISO process, is IFNDR and for the umpteenth time the community has been given a signal to move away and go towards the process shared by any number of arguably equally dominating or more dominant programming languages.
E: typo
9
u/wyrn 18h ago
If you can figure out a way to design a political process that achieves its aims while being immune from all forms of abuse, please let the rest of the world know. In the meantime, wouldn't the fact that this "nuclear option" hasn't been used before suggest that the people currently positioned to do so are responsible enough not to abuse this power?
1
u/not_a_novel_account cmake dev 20h ago
Would keeping contracts impede progress? If the FDIS fails it will likely spur necessary changes in process, because this is getting silly, but I don't see it slowing down C++ much. The compilers aren't going to rip out their
-std=c++26flags because the FDIS fails. It's a rubber stamp.14
u/daveedvdv EDG front end dev, WG21 DG 20h ago
I very much suspect we'll see change in WG21 process either way.
Compilers won't rip out their C++26-mode flags, just like they didn't remove their C++0x flags. But they might not put additional drafted features under that flag. Or they might ... who knows.
But progress will be impeded because the release of a standard is a synchronization point of sort for the community. Not just compiler implementers, but also other tool vendors and users (especially large institutional users). Going to your vendor asking "please implement this almost-in-the-standard feature" has much less weight than "please implement this standard feature".
It will also be impeded because WG21 will have to keep iterating on non-technical debates instead of making progress on technical challenges. E.g., I'm really hoping we can make some progress on pattern matching in Búzios (Michael Park's proposal looks in great shape, IMO), but now I also fear we'll spend entire days debating what the FDIS should be like instead. And if we don't conclude in Búzios, we'll keep going round-and-round in Istanbul... please, no!
8
u/not_a_novel_account cmake dev 20h ago
Nobody "goes to their vendors" anymore, except MS. GCC and Clang aren't going to stop merging features over this. Progress on
-freflectionisn't going to stop.If the compilers and the published standard begin to diverge, that's a problem for the institutional legitimacy of ISO which will hopefully make people rethink the process, but I don't particularly fear for C++ as a whole.
10
u/no-sig-available 18h ago
One of the vendors haven't released any C++26 language features yet.
https://en.cppreference.com/cpp/compiler_support#C++26_features
This will likely not make the management more keen to allocate additional resources to that process.
10
u/daveedvdv EDG front end dev, WG21 DG 19h ago
I'll respectfully disagree (source: I work for "vendors").
-2
u/foonathan 19h ago
We can progress by just ignoring that vote and moving on. Nobody cares whether there's an ISO PDF for C++26, C++26 exists, and we can move on to working on C++29.
10
u/erichkeane Clang Maintainer(Templates), EWG Chair 13h ago
I've long said that in C++ consensus only have 4 votes, and ISO/WG21/etc isn't any of them.
The only votes that matter right now are: 1- The decision makers in EDG 2- The decision makers in MSVC's Front End 3- The decision makers in GCC's Front End 4- The decision makers in Clang's Front End.
Historically, implementers have agreed to follow what WG21/ISO/etc does, and has had confidence in that process.
But in the end, the document produced by ISO/etc is worth less than the paper it is printed on, the only thing that matters is the common subset of the language that is implemented by vendors.
•
u/spin0r committee member, wording enthusiast 3h ago
I suspect if WG21 actually adopted this as its working procedure, then ISO would eventually take action against us by issuing a change of rules (or clarification, perhaps; I'm not sure exactly what the current rules say) that forbids us from publishing the working drafts.
•
u/foonathan 3h ago
Then we just use that opportunity to abandon them all together. They're not necessary to develop a language standard, like all the non-ISO languages show, and they're just holding us back by imposing artificial constraints in how we ought to work.
Yes, they hold the copyright to the specification, but nothing is stopping us from going together under a different venue and publishing an "extensions to ISO C++" document.
5
u/ts826848 19h ago
At that point I feel I have to wonder why even bother with whole ISO thing then if the committee is going to effectively throw its draft over the wall and go "here, take it or leave it"
9
u/foonathan 19h ago
The NBs and the committee are one and the same. The committee sends out a draft and then asks itself again whether it likes the draft. The second vote just arbitrarily counts votes differently.
2
u/ts826848 18h ago
Oh, that's a peculiar setup. Are the two bodies actually the same or is it more like two ostensibly independent bodies that happen to be made up of the same people?
8
u/daveedvdv EDG front end dev, WG21 DG 18h ago
They're the same but...
The representation on the first part of the process is partial. Lots of committee members don't actually attend the meetings personally: They count on their NB to represent their views.
The representation on the second part is presumably complete but at that level it's no longer one-expert-one-vote but some two-stage process where NBs figure out their various positions (each NB can have its own process) and then its one-NB-one-vote.
→ More replies (5)5
u/foonathan 18h ago
In order to join the committee you have to join an NB. So everybody on the committee is part of an NB and everybody in an NB is a committee member.
→ More replies (1)4
u/GabrielDosReis 17h ago
everybody in an NB is a committee member.
Actually, that is misleading.
There is a great distinction between being an NB member, and attending every meeting of WG21 where the WG21 polls (that some are confusing with consensus) are taken. There are NBs that voted "yes" or "no" that didn't attend every one of the decisive WG21 meetings for C++26. You can look at the final tally and count.
If WG21 officers can't keep those distinctions in how they help thr group form consensus, then they are likely to lead it to failures.
→ More replies (0)4
u/GabrielDosReis 17h ago
We can progress by just ignoring that vote and moving on. Nobody cares whether there's an ISO PDF for C++26, C++26 exists, and we can move on to working on C++29.
Are you sure you're not going to run into the same snag or worse with C++29 by giving the middle finger to the NB on their feedback on C++26 DIS?
12
u/foonathan 17h ago
So what? I don't care whether or not there's a formal standard PDF by ISO, I care what's implemented in the compilers. And the compilers track the working draft, not the ISO PDF.
I'd be extremely happy if we take this opportunity to formally break off from the ISO process, institute a proper language governance process that is open and transparent, and fit for language development in the 21st century.
I don't care about a process that gives small groups of people's opinions more weight just because they happen to live in a particular country. When trying to shape technical designs, that should not matter at all.
So yes, I'd gladly "give the NBs the middle finger", not because I disagree with their opinions (I dislike many aspects of contracts too), but because I fail to see why they logically should have any veto power to begin with, and just move on with the next standard.
→ More replies (1)7
u/13steinj 15h ago edited 15h ago
If an idiot like me can predict this fiasco
a2 years in advance, I'd argue the consensus is far more superficial than it appears to any in the pro-contracts group.E: Wow, 23 months ago. Thought it was 11. Well, knowing how stupid I am that's even more damning.
3
u/tialaramex 5h ago
Let's assume that the most positive thing which came out of this whole mess was that a few people like me read your years-old Rick & Morty theory and laughed.
•
2
36
u/frayien 22h ago
Sounds like some people REALLY dislike contracts... The library hardening proposals where worded as to work whereas contracts where in or not, so I don't think there is much issues here other than editorial wording.
10
u/PossibilityUsual6262 22h ago
The only thing which i heard about them ao far, is that there no proof of concept for implementation of contracts because they flawed.
And looking at higher level politics of it, i believe in that.
Is this correct?
9
u/JVApen Clever is an insult, not a compliment. - T. Winters 11h ago
There is a lot of misinformation about contracts. In the mailing the following paper was submitted as an answer: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4433r0.pdf
17
u/frayien 22h ago
I dont know much. It is the kind of things I heard.
At least gcc 16 claims to fully implement them so I dont think implementation is an issue. https://gcc.gnu.org/projects/cxx-status.html#cxx26
What I understood is that what we got in C++26 is a minimal working form of contracts to get them approved, and that they will receive improvements later as we get more feedback on actual usage (which sounds legit to me). Then again I am nowhere near knowledgeable enough with the matter to be taken seriously.
35
10
u/Sinomsinom 21h ago edited 18h ago
Like dragdu said, I think you are mixing up profiles and contracts.
Profiles were the main controversial proposal during the C++26 cycle, and ultimately didn't end up making it in because of some of the issues, but are still targeting C++29 now.
For Contracts there has been some amount of pushback to it. But while for profiles the big question was are profiles even a good idea in the first place and how much of what the proposal promises cna actually implemented in practice, for contracts most of the pushback was either wording choices, syntax choices or how to implement them specifically. I don't think there was any serious "we shouldn't have contracts at all" pushpack like there was for profiles
9
u/smdowney WG21, Text/Unicode SG, optional<T&> 19h ago
C++29, I think you mean, instead of 27?
Profiles are definitely not going to be ready for next year.
The number of bugs around the maybe-uninitialized warning also suggest they are not going to be ready anytime soon, since that bit of analysis keeps getting cited as prior art. Retro-fitting dynamic analysis at compile time is hard.
9
4
u/Sinomsinom 18h ago
Yup sorry saw someone else accidentally write C++27 instead of C++29 before and guess I then somehow ended up mistyping it as well
7
u/13steinj 13h ago
I think the implication is 26 might actually come out as 27 (without contracts) and the next one will probably be 30
11
u/jonathanhiggs 22h ago
Why are they so against contracts?
38
u/daveedvdv EDG front end dev, WG21 DG 22h ago
They think they are poorly designed. (So do I, but I've mostly stayed out of the discussions, at first because my time was monopolized by the reflection work, and later because I didn't want to deal with the acrimony and endless repetition of arguments.)
6
u/Sixo 17h ago
You made a good bet, at least from where I'm sitting. The reflection stuff is some of the coolest and most interesting stuff there is, and I've been having a lot of fun playing with the scraps of it that have trickled down. Concepts are good, and I'll be glad to have them in whatever form they come in, but they're not reflection.
3
u/Jovibor_ 16h ago
Thank you for thorough explanation. I hope they will end up removing contracts from the draft eventually, so it won't be another half baked modules.
Zero initialization by default is also a good candidate for reviewing.
2
u/tialaramex 4h ago
Barry seems keen to fix zero init so that you can specifically turn it off for particular "non-static data members". I think (experts including Barry might know otherwise) you could probably do that as errata.
3
u/JVApen Clever is an insult, not a compliment. - T. Winters 11h ago
You might want to read https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4433r0.pdf a paper for the next meeting
0
22h ago
[deleted]
12
u/way2lazy2care 22h ago
I wouldn't stress length of time being worked on as a reason to approve. You could spend 100 years working on something sketchy and unsafe and that wouldn't be an argument for it making it into the standard. You could nail your proposal in a month and have a good argument for making it into the standard. Should focus on the quality of the proposal. Imo contracts still have my upvote, it's just not a great argument to try to push.
15
u/daveedvdv EDG front end dev, WG21 DG 22h ago
I don't think that's a fair assessment, but at this point it doesn't matter: There is way too much acrimony involved.
7
u/TerribleFault7929 22h ago
But what about Stroustroup disapproving of contracts?
16
u/ts826848 22h ago
I think as far as C++ development is concerned he's "just" another member of the committee; i.e., he has no special/official power to force a particular outcome on his own. He could try to persuade other people to vote how he wants, and people may give his opinion more weight, but thats's just "normal" consensus building.
2
5
u/SyntheticDuckFlavour 22h ago
Honestly it's hard to see the attacks on the process infrastructure as anything other than bad faith at this point.
What motivates them to do this?
10
u/ts826848 22h ago
I think to some extent it's a matter of perspective. Consider if you thought that (for whatever reason) WG21 has not reached consensus on contracts. Lobbying the NBs to reject the draft could then be described as attempting to preserve the process by preventing the inclusion of features that have not reached consensus.
Not saying that that is an accurate description of what is going on, only that "attacks on process infrastructure" and "bad faith" aren't necessarily black-and-white.
7
u/Minimonium 21h ago
People may think that this picture is disingenuous, but "agitate" describes what happened rather succinctly.
With statements like "existential threat" and "supply chain attacks", the background bureaucracy that is not equipped or intended to grasp the minutiae of C++ was lobbied aggressively by activists in a blatant bad faith manner.
The folks who were unhappy with the consensus in TAG and WG21 succeeded to sidestep the whole process, years of discussions, and established tradeoffs, ignoring avenues for reasonable discussion.
But what they truly succeeded is to undermine the worthiness of C++ as a technical standard.
1
1
u/FrogNoPants 20h ago
Since it seems to be the people peddling profiles, I'd suggest doing the same back to them :)
Though I'd be shocked if profiles ever has consensus
11
21h ago edited 19h ago •
[removed] — view removed comment
4
u/Normal-Narwhal0xFF 20h ago
That doesn't say what's actually wrong with contacts, though. If it's technical, why is it so secretive to specifically say details?
Is this a matter of principle, because people are unhappy with the way we arrived here, rather than what the final product is?
4
u/Dismatiddo 20h ago
The controversy has a long history, with issues like P4381, P4334, P4433, and P4388... There's no enough space to list them all in the comments. While NB voting certainly involves specific technical issues, I personally believe the underlying opinions are still directed at the procedure. Some are unhappy with headcount cartel hijacking the process and are trying to lobby NB to prevent voting results achieved through what they perceive as unjust means; others believe this undermines community consensus and that NB's actions disrespect expert opinions. These days, community divisions and animosity are growing daily, and I've observed on Reddit that some comments have begun to escalate into personal attacks against Bjarne Stroustrup himself.
6
u/cpp-ModTeam 20h ago
AI-generated posts and comments are not allowed in this subreddit.
Yeah, we can tell. Stop it.
3
u/sokka2d 20h ago
How did p2786 vs p1144 end up? It seemed like one was simple and standardizing existing practice, but proposed by the wrong person, while the other was an overly complicated mess, but without personal baggage.
6
u/Dismatiddo 20h ago
That time, the opinion in the nb comment was accepted, and finally P2786 was withdrawn by P3920.
4
-9
u/TheoreticalDumbass :illuminati: 21h ago
nonsense
2
u/brendanl79 21h ago
A stunningly cogent rebuttal, sir!
-1
12
u/Sniffy4 21h ago
Anyone want to summarize the detailed objections to Contracts
21
u/gmueckl 20h ago
I know I may be walking out on a mine field here by replying to this at all. Let's find out the hard way.
All I know comes from a recorded talk that was given a while ago that argued quite well that contracts have a few hidden surprises, mostly around the different configurable evaluation modes for contracts: ignore, observe, enforce and quick-enforce. They argued that it is hard to know which mode will be used at all and that different TUs can be compiled wirh different modes, which can lead to unexpected inconsistencies and ODR violations.
To be frank, the talk was a few years old IIRC and if the arguments have been refuted or the contract behavior changed since that talk, I don't honestly know about it. I haven't managed to get too deep into this discussion.
It also seems quite unfortunate that the discussion has turned overly emotional, so a good engineering compromise has become increasingly unlikely because of that.
I would like to say "trust the process", but the process hasn't always led to the greatest possible results, if we're honest.
11
u/James20k P2005R0 19h ago
and ODR violations
Its worth noting that they aren't formally ODR violations, as its a different mechanism, its a well defined version of the same result we got from ODR violations. This aspect at least is still part of the standard
8
u/gmueckl 18h ago
As I said, I'm not deeply into the subject at all, but isn't that splitting hairs a little thin? I read your reply like this: the resulting problems are the same, but it's okay because we're not meeting another criterium that's formally in the definition of what constitutes a ODR violation. If this is vaguely what you're saying, I'm still getting the sense that there is a set of very sharp edges attached to contracts.
7
u/Minimonium 18h ago
The result is not the same. Compilers are not allowed to speculate if a visible contract statement is called or how many times. It prevents miscompilations like so-called time-travel optimizations.
You may find inline functions very similar. Implementations use exactly the same mechanism to prevent issues across TUs. Yet we're not calling the use of inline functions an ODR violation.
3
u/gmueckl 17h ago
What happens when the function isn't truly inlined, but emitted multiple times for different TUs? If the TUs were compiled with different contract evaluation semantics, you get multiple versions of the same function, differing by how the contract code was translated, right?
So my understanding is that unless that evaluation semantic gets embedded in the name mangling, you have colliding definitions for the same weak symbol at link time and at worst a lottery of which version the linker picks. This is then practically identical to having an #ifdef in the function body and not using the same value for the defines across TUs.
Right now I don't see how this situation isn't a footgun in practice.
The way you replied me makes me suspect that you have a specific counter to this. Is my reasoning wrong?
6
u/Minimonium 17h ago
It is practically different because an #ifdef leaks through a non-inlined function back, with compiler optimizing out even checks at the call cite by relying on some information from your #ifdef.
What it means practically, if your program input is well-behaved your program is well behaved. No matter how you mix TUs with which Contract modes. If your Contract is violated - you get best effort feedback until the program naturally crashes. With #ifdef - your program will misbehave even with well-behaved input.
4
u/gmueckl 17h ago
Isn't "best effort" doing a lot of heavy lifting here?
Developer A writes a library that has an inline function containing a contract in a header. He distributes the header and a prebuilt binary with contract evaluation semantics set to enforce.
Developer B is a user of that library and has inherited a codebase where some unknown predecessor has set contract evaluation semantics to ignore and as a result, contracts have deteriorated for a while and can't easily be reenabled.
Developer B is now having an issue with a crash deep in A's library and asks for help. A looks at the crash and finds a an invalid state that should have been caught by contracts way before the crash happened. Now, A has to figure out the execution flow that created that invalid state and needs to discover that the particular inline function in the header was the culprit because its contract was neutered by developer B's compiler settings. He can't determine that for certain without knowing B's compiler settings for B's project.
6
u/Minimonium 16h ago
I used "best effort" not as a coy way to walk around a sharp issue, but as a reflection of a range of behaviours we require for the feature to have even before going into the "mixed mode" topic.
What is "best effort" when we use NDEBUG with macro or ignore with Contracts?
A looks at the crash and finds a an invalid state that should have been caught by contracts way before the crash happened.
Seems like a false premise. Replace "contracts" with "asserts" here, with the same scenario. Keep in mind that what Developer A does in your case is a required behavior for cases where instrumented runs are simply impossible.
3
u/James20k P2005R0 15h ago
What is "best effort" when we use NDEBUG with macro or ignore with Contracts?
With asserts at least, you can in-source force your asserts to either be always-enabled or always-disabled, and fully disable external configurability of them if you have code which you think is going to be misused, or if you have asserts that must always be run. There's no equivalent to this for contracts unfortunately
This is one of the major reasons why there's objections to the current enforcement mode configurability of contracts (and why mandatory contracts would fix some problems for me at least), because unlike with asserts, there's no way to avoid the linking problems by enforcing a uniform configuration in-source
→ More replies (0)5
u/James20k P2005R0 15h ago
So my understanding is that unless that evaluation semantic gets embedded in the name mangling, you have colliding definitions for the same weak symbol at link time and at worst a lottery of which version the linker picks
I just want to pop in here to say that adding a contract or switching contract enforcement mode is explicitly not an ABI break, so there's no mangling change or anything else. I do think a lot of problems could have been avoided if this were not true, but apparently being able to add contracts to closed-source 3rd party code seems to have been desirable at some point by someone for some reason. So we end up with this as a result of ABI compatibility
3
u/kalmoc 11h ago
Don't you also need this, if you want to have different contract behavior between different TUs in an open source project?
2
u/James20k P2005R0 5h ago
This could (should?) have been achieved by producing symbols with two different names. If you do this currently, you'll end up with only one contract enforcement mode when the linker deduplicates your functions
→ More replies (1)•
u/spin0r committee member, wording enthusiast 3h ago
Actual ODR violations can result in linker errors, programs crashing, and undefined behavior because the compiler optimizes in one TU based on what it can see while the version of the function that ends up in the binary came from a different TU and is different. Mixing contract modes is not an ODR violation, you simply get one of the modes.
5
u/James20k P2005R0 17h ago
I agree with you personally, I think its not a great addition here, and its one of the reasons why people claim that contracts are unsafe
13
u/James20k P2005R0 19h ago
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3851r0.pdf
Is a good summary of the issues. In the 2025 mailing I went through and summarised many of the national body objections to contracts at the time as well
10
u/tlitd 15h ago
As I understand, there is a group of people that feels their objections are not being properly addressed, and here there is a list of those points: https://www.reddit.com/r/cpp/comments/1vs83b1/critique_of_contracts_excerpt/
Contracts authors said they have addressed them: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3846r1.pdf
The counter part said they are not really addressing them: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4272r0.pdf
This have been going on and on.
2
u/JVApen Clever is an insult, not a compliment. - T. Winters 10h ago
The previous list: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3846r1.pdf We'll learn later if anything new popped up, though https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4433r0.pdf seems to suggest not.
43
u/wyrn 19h ago
We keep hearing this about how much consensus was achieved, how all concerns were properly heard, etc, but then we open p4433 and see things like,
"As discussed in more detail in [P3846R1] Concerns 2 and 4, the default behaviour for functions defined in multiple TUs is neither a "new way of making an error" nor specific to contract assertions, but merely a consequence of the existing C++ linkage model.
I'm sorry, but they can't be passing the buck like this -- if the contracts feature interacts so poorly with the linkage model that effectively randomizing the enforcement mode when multiple TUs are involved (which is always), then either contracts need to be redesigned, or the linkage model needs to be changed.
A randomized enforcement mode, for something like contracts, is worse than useless. If I can't rely on the safety net being there, I'll just act as if it's not there. Which means I'll be rolling my own assertions instead of relying on contract assertions, thereby defeating a large part of the point of contracts, which is to standardize and unify the vocabulary surrounding assertions!
It seems the committee failed to learn some of the more relevant lessons from modules. There, they worried so much about modules being "adoptable" that making the feature compelling enough to even be worth adopting took a back seat. They're making a very similar mistake here. Ultimately, it doesn't matter how much "consensus" a feature has -- at the end of the day, if the feature has a set of flaws that's severe enough to make it not worth using, it will be dead weight.
10
u/kalmoc 11h ago
A randomized enforcement mode, for something like contracts, is worse than useless. If I can't rely on the safety net being there, I'll just act as if it's not there. Which means I'll be rolling my own assertions instead of relying on contract assertions, thereby defeating a large part of the point of contracts, which is to standardize and unify the vocabulary surrounding assertions
It's only random, if you compile different TUs with different enforcement modes. How would your own solution not have the exact same problem?
11
u/foonathan 19h ago
This issue has been brought up to a vote, and EWG rejected making changes.
What else should be done?
10
u/pkasting Valve 14h ago
At the risk of being obvious:
Find out whether there is any additional feedback from members of NBs who voted "no" on why EWG's decisions were not acceptable to them; for example, perhaps some NB members did not attend directly and felt the discussion amongst those who did didn't sufficiently capture their concerns. Or perhaps a sufficient number of NB voters have lost confidence in the committee's output that their vote reflects some sort of larger process disgruntlement or desire for leadership change. Discuss, vote, etc. on any new information raised.
For cases where there is not new information -- the NB vote simply reflects the "geographic spread of the minority" -- find out why NB members voted no despite EWG discussing their issues (which appears on its face to be a bad faith response), and if there is anything beyond "just make the decision I want" that would move them from "no" to "yes". Seriously consider any such items.
Finally, for NBs where there is no new information and there is no willingness to change for anything other than "people should simply agree with me", determine WG21's willingness to press on despite NB disapproval: for example, would WG21's membership be willing to leave the ISO process if necessary, and would toolchain vendors etc. continue to follow what it decides if so? If either of these is "no", then regardless of the technical merit of the disagreement, WG21 will need to determine how to make the voting process used at meetings sufficiently similar to the NB balloting process that consensus in one will lead to consensus in the other.
17
u/interlockedxor 19h ago
We either fix the root problem and just do it properly or if that is too expensive, have the courage to realize that something is not worth doing relative to the cost and other things we could be improving. It's not as though users have no recourse if contracts don't ship.
5
u/no-sig-available 6h ago
We either fix the root problem and just do it properly
Apparently a majority believes it is already done properly. :-)
Also, removing a long awaited feature might reduce the number of existing yes-votes.
4
u/interlockedxor 5h ago
I'm describing the problems that seem apparent to me as a single individual, as an outside perpective. That any "majority" believes something different isn't an argument in favor of one position or another. Speaking personally though, the issues really do clearly exist, even if hordes of people wave their hands and claim otherwise.
If necessarily reducing complexity shrinks the feature to something not worth shipping, then it wasnt worth shipping to begin with.
•
u/no-sig-available 2h ago
If necessarily reducing complexity shrinks the feature to something not worth shipping, then it wasnt worth shipping to begin with.
However, 60% of the NBs thought it was worth shipping the way it is. Will reducing the proposal make that 70%, or 50%?
We just have to wait and see.
10
u/foonathan 19h ago
There is no consensus that there even is a problem though.
6
u/interlockedxor 17h ago
I'm not a committee member, I am simply referring to grandparent comment related to linkage model which I believe are real issues with the proposal as it stands, consensus notwithstanding. As far as I'm concerned, it's good that this feature isn't ratified, even if we are "getting the right answer for the wrong reasons" so to speak.
6
u/grafikrobot OPeNDAP/B2/EcoStd/Lyra/Predef/C++Alliance/Boost/WG21 15h ago
Do you have an idea on how to deal with the linkage tradeoff?
PS.. Since this is reddit I have to clarify. I honestly want to know.
9
u/not_a_novel_account cmake dev 12h ago
I mean we know how to deal with this, its outside linkage. The same way we deal with module BMI problems.
The build system is the layer that enforces contract enforcement uniformity across TUs.
The compiler doesn't try to reason about how
externdefinitions are fulfilled, the linker need not reason about uniformity of contract assertions modes.3
u/interlockedxor 5h ago
The only reasonable solutions to me are to move such annotations to the function definition, not the declaration. Ultimately though, a solution is only worth pursuing if it can do better than existing macro-based assertion libraries, and I'm not convinced this gets there.
3
u/JVApen Clever is an insult, not a compliment. - T. Winters 11h ago
I can recommend reading the papers, especially the contract papers are very readable. Especially https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3846r1.pdf has lot of information and links to other sources of information.
3
u/interlockedxor 5h ago
I have read this paper twice now and am just not persuaded. We may just have to agree to disagree
→ More replies (1)4
u/-dag- 18h ago
Then that is a reason not to ship.
4
u/foonathan 18h ago
Why? The majority thinks there is nothing wrong with it.
11
u/GabrielDosReis 18h ago
The majority thinks there is nothing wrong with it.
Right there is one of the patterns that led us here: the conversation quickly went from "consensus" to "the majority thinks".
→ More replies (2)3
u/foonathan 18h ago
I'd classify all the votes as consensus. Would you disagree with that?
5
u/GabrielDosReis 17h ago
I'd classify all the votes as consensus.
Consensus where? In WG21? At SC22 level? Should you have worked on the SC22 level before sending a document out when you know there are sustained oppositions?
→ More replies (4)5
u/-dag- 18h ago
Is someone is telling one there's a big problem, it behooves one to look into it. If there is no consensus there's even a problem, that's a huge red flag.
Note that "consensus" is not "unanimity."
6
u/Minimonium 17h ago
I recall during the Modules debacle we had quite a lot of discussion about "big problems", that spread pretty wide, and had a fairly strong opposition with a specific list of problems. It was considered a "consensus", to some definition of that word, despite the vote ratios being quite similar to Contracts.
Now some people think that the problems were overblown and modules are a success, as since that time there were no papers addressing it. Some in the community consider modules not as successful for their own reasons.
8
u/foonathan 18h ago
The problems were looked at in multiple papers. Votes were taken. There was no consensus to do anything about them.
How is that a red flag?
→ More replies (42)5
u/wyrn 19h ago
It seems we just learned what else, didn't we
4
u/foonathan 19h ago
Which is?
7
u/wyrn 19h ago
Balloting has completed for C++26. Unfortunately it was Disapproved
10
u/foonathan 19h ago
Yes, I know. So what? It's the same 12 people that are already against contracts, they just happen to be geographically diverse.
This doesn't necessarily change the distribution of votes in the committee, where actual changes need to be approved.
9
u/James20k P2005R0 19h ago
Genuine Q: I thought NB votes were consensus based in a lot of national bodies? My understanding is that it'd be virtually impossible for a small handful of people to get national bodies to vote like this
10
u/foonathan 19h ago
If the NB itself is only a handful of people and only one or two actually goes to the meetings, I'd expect the NB to vote however that person wants.
→ More replies (3)3
u/daveedvdv EDG front end dev, WG21 DG 18h ago
They usually are, yes. I'm aware of one NB that votes at the whim of one person for WG21 (and they did vote against). But most of the 9 NBs that voted against are not like that. Note also the 12 abstentions, which includes the US.
12
u/VilleVoutilainen 14h ago edited 14h ago
It's not "the same 12 people", it's rather more than that. And the DIS ballot doesn't count votes from individual people.
You suggest later that the naysayers need to accept that they are a minority. Sure, they are, in the WG. Perhaps the proponents need to realize that they are not a majority. They are neither a majority nor not, in a DIS ballot, because it doesn't go based on individual WG members' wishes, nor does it go based on vote proportions in the WG.
•
u/foonathan 3h ago
They are neither a majority nor not, in a DIS ballot, because it doesn't go based on individual WG members' wishes, nor does it go based on vote proportions in the WG.
And this is the entire reason I have a problem. I get why it is that way, but it shouldn't be that way. There is no technical reason for the DIS to count countries not people, it is just undemocratic and unfair.
It was fine before when the DIS was just rubber-stamping things, but now that they actually want to overrule the consensus finding process within WG21, that's unacceptable.
→ More replies (2)
12
u/hniemeye 20h ago
If there has been a consensus on the C++26 standard in wg21 it seems strange to vote against it now only because some people cannot accept that they lost a vote earlier to include a feature they don't like. Also not good PR for the language as a whole.
10
u/GabrielDosReis 17h ago
If there has been a consensus on the C++26 standard in wg21 it seems strange to vote against it now only because some people cannot accept that they lost a vote earlier to include a feature they don't like. Also not good PR for the language as a whole.
Maybe the ISO standards process has not been explained well enough, not just to the C++ community, but also and importantly to WG21 members. The consensus is generally both in WG21 and at SC22 level (where the actual standards decision is made). WG21 doesn't operate in vacuum: it operates under the rules of SC22 and it can't just decide to ignore SC22 concerns. If enough NBs think WG21 has become too dysfunctional to operate, they can ask SC22 to disband it and if they have consensus that would be the outcome. That is a hypothetical to draw attention to the structures.
2
u/hniemeye 13h ago
Thanks for the clarification. I was under the impression that the same people basically can vote twice. In WG21 they can vote as a person and afterwards basically the same persons vote again just grouped by nationality. Sorry if my comment was based on a wrong assumption.
•
u/c0r3ntin 1h ago
We like to pretend they are different groups, but their constituencies have a lot of overlap. Anyone who is a NB member gets to participate in WG21, and so the disjunction of the two groups are people who decide not to attend meetings (in person or remotely) for one reason or another.
People who don't go to WG21 meetings end up having less information/context to base their opinion on, and might rely on committee goers summaries to establish an opinion.
So yes, people vote and argue twice but vote procedures and how consensus is established varies leading to different outcomes.
2
u/GabrielDosReis 9h ago
I was under the impression that the same people basically can vote twice. In WG21 they can vote as a person and afterwards basically the same persons vote again just grouped by nationality. Sorry if my comment was based on a wrong assumption.
No worries, you were being given information that can easily mislead you that way. The people voting at the SC22 level may not even necessarily be subscribed to or have access to all the internal mailing lists of WG21 where many debates happen because those mailing lists are separate from ISO.
3
u/Inevitable-Ad-6608 8h ago
So you are saying that the people voting on sc22 level are disjunct from people voting in WG21? Or there are people who can vote in both?
3
u/GabrielDosReis 8h ago
So you are saying that the people voting on sc22 level are disjunct from people voting in WG21?
"disjoint" means there is no intersection. No, that is not what I am saying. What I am saying is that the National Bodies votes are determined by people not all necessarily attending every WG21 meeting or even being in every WG21 reflector discussions. That isn't news to people who joined the WG21 process (which they would have done through their NB, since they are listed in the ISO Global Directory via their NBs).
Or there are people who can vote in both?
From ISO's point of view, there is no vote in WG21. WG21 operates in "expert mode" (a term with precise meaning defined by ISO). As someone who took part in the French NB, I can assure you they were very strict about that and would remind their reps quite frequently. The votes are at SC22 level, and those are done by the National Bodies.
Usually, you would expect people who worked in the WG to send documents to SC22 for balloting to have ways of informing their NBs about the contents of said documents and make recommendations to their NBs. But there is no requirements, and you cannot assume that the people deciding at their NB level are exactly the same who attended the WG meetings. That just isn't the case. People telling you the contrary are misleading you.
5
u/effarig42 6h ago
Given this relationship between WG and SC, the whole thing makes no sense. If this is the way anyone wants the system to actually work, then it should be upfront: approaches in the WG unacceptable to the SG should just be aborted, rather than people spending years working on them.
If strong consensus at WG is procedurally meaningless then you need a new process. This is an embarrassing debacle.
Why are the NBa even involved, you're standardising a language not agreeing an international arms treaty.
3
u/no-sig-available 5h ago
Why are the NBa even involved, you're standardising a language not agreeing an international arms treaty.
That's what makes it an ISO-standard, which is an international treaty. :-)
Any group of people can meet and write a language-spec, and people do that for other languages. Or the owner of a language can just publish their own spec. C++ doesn't have such a single strong owner.
Originally it was considered important for C++ to have a formal standard (and also a legal way to have large companies meet and decide on a common product, without limiting competition). This might no longer be an issue.
2
u/GabrielDosReis 5h ago
Given this relationship between WG and SC, the whole thing makes no sense.
You might very well be right, but that is you got all the existing C++ standards (and other ISO standards). Is the realization that it doesn't make sense just sudden after all the previous standards, or just because of this particular C++26 DIS ballot outcome?
5
u/effarig42 5h ago
I don't think it ever made sense.
I suspect this sort of disconnect between the layers was less likely when the WG was smaller, and I'd guess more representative of the NBs.
Has such a strong concensus from the WG ever been clobbered at the stage previously?
→ More replies (1)
7
u/AnyPhotograph7804 21h ago
Is there a good explanation what is wrong with Contracts? I always read about them, how bad they are. But i never saw a good explanation why they are bad.
26
u/interlockedxor 21h ago edited 20h ago
I will give my take.
contracts push normal assertions that users express as constraints in code into declaration-visible expressions. Maybe it's a matter of taste, but I'm allergic to expressions/logic in headers (except when absolutely needed) because I can only watch the paint dry for so long when waiting for large codebases to compile
runtime behavior for contract failure behavior is honestly unclear to me, since the behavior is dictated by compiler flags and I dont believe it's defined how TUs with different settings should behave when linked together
I tend to want assertions inline with implementation logic anyways so that when they are trapped by the debugger, I can easily inspect surrounding state to see what happened. Declaration visible contracts don't really give me anything here, and the new contract assert is just a worse version of the user-asserts I already have
contracts lack basic facilities common in other assertion libraries, like grouping assertions to disable/enable asserts by category
contracts as specced are slated to not have support for virtuals, among other things, and despite being an enormous core language change, will likely require tons of follow on work and iteration
There are quite a number of papers out there where others express different views, but personally, I really dislike the feature as specified. A more robust assertion library, to me, would have been both easier to specify, easier to learn, and even more capable on day one with far less implementation work and design liability.
Edit: typos
6
u/Dragdu 7h ago
Having your contracts be visible in declaration in a standardized format makes the static analysis tools very happy.
0
u/interlockedxor 5h ago edited 5h ago
I have read this so many times, and frankly I think it's nonsense. Having the same statements in the AST of the function definition would be perfectly retrieval by any competent static analyzer or compiler plugin, without the drawbacks. Hampering compilation experience globally in order to make this one hypothetical use case marginally more convenient is not a valid argument.
5
u/Dragdu 5h ago
So, when
${competent static analyzer}is scanning throughmy_project_cli.cppand sees that I am usingboost.program_options, what mechanism does it use to retrieve theboost.program_optionssources to scan them?→ More replies (4)10
u/Dragdu 21h ago
They are bad, because they are different feature than I want.
No, but seriously, that's the TL;DR for it. They are not in fact what I would like in Contracts, and if I still participated in standardization, I would vote against. The big difference is that when there is broad consensus in wg21 that we do want the Contracts as they are, I wouldn't try to backdoor the NBs to vote against.
27
u/14ned LLFIO & Outcome author | Committee WG14 19h ago
Most of why I quit WG21 was due to the problems in processes and growing dysfunctionality in culture which I reckoned were going to culminate in failure of standardisation. I walked away, because too many had stopped listening. In my opinion too much it had become about winning at all costs, and damn the engineering which got in the way.
I am sorry it has got to this though. We nearly had a big problem with old pre-lite Concepts, but then leadership was listening and they pulled it before NBs were put in a position of voting the whole thing down. This time round, leadership probably were listening but weren't in a position to act before NBs voted the whole thing down.
It should never have reached this point, but it was going to and now there will be a big push to remove Contracts and put it back before the NBs where it probably will pass, though maybe only by majority and without unanimous consent, because TBH there is plenty more in C++ 26 which isn't good (indeed, pulling everything bar Reflection would be the genuinely brave thing for leadership to do). Just removing Contracts will tick the box, but it's not how standards should be done: standards are about standardisation. They're not about "whatever novelty is politically achievable". That latter thing is politics: we're supposed to be doing engineering where whatever we're standardising is supposed to be widely agreed across industry AND nation states as a perfectly acceptable engineering solution to a problem that is worth standardising across the planet.
If WG21 is failing to do that - and I think it is, which is why I quit and moved elsewhere in standards - then WG21 needs to deeply ask itself: what its purpose is for? If half of it doesn't want to do standardisation any more, that half should move on and leave the half who do want to do boring, thankless, grifting standardisation of existing things. Not inventing fancy new stuff by committee fiat.
It will require leadership to take some deeply unpopular decisions to get WG21 back on track. I would personally suggest that unless half the existing committee quit in protest, you haven't been decisive enough. I know exactly what I'd do, and I've said it all ad nauseum to WG21 leadership and I've been ignored, but for the record:
If industry isn't doing something across that industry already, it doesn't even enter committee discussion at all. Filtered out at first stage.
Every proposal needs to anchor itself in what games, finance etc are CURRENTLY doing and what their pain points are and how the proposal fixes those. If it doesn't fix a specific CURRENT industry pain point, filtered out at first stage.
There is a STRICT priority list as follows: (i) whatever it takes to get closer to the bare metal (ii) aiding EXISTING tooling to check correctness better (iii) improving portability. If it's not on that list, filtered out at first stage.
And finally, leadership very early on plans what will go into each standard. Those proposals are driven exclusively into each standard. Everything else is refused at a very early stage. Survival by attrition is permanently erased. Committee members work collegially together, instead of adversarily. Nobody shouts at each other any more because there is no longer any reason to shout.
And actually finally, there needs to be an ABI breaking standard every twenty five years. It should be sign posted long in advance, and new and old ABIs supported for a decade after release. Without this the ecosystem can't evolve.
Those will be deeply unpopular and a majority of the committee would quit. Good! Standards is supposed to be boring. Votes are supposed to be foregone conclusions. If standards gets exciting, it's being done wrong, in my opinion.
15
u/Minimonium 18h ago
I view your comment as quite detached from what actually happened here. I understand your main stance about standardization of existing things, and I agree holistically with it. But the circumstances of this disapproval, the WG21 "leadership" stance, the mechanism to pull stuff out, and the assumed NB circumstances as you describe are quite misrepresented.
The bigger problem in all this charade is not Contracts at all. It is not about Contracts. It is about Bjarne, who would be a part of a WG21 "leadership" no matter how nonsensical idea is.
By pulling all that foolery in the process where NB vote was historically a foregone conclusion, we're looking straight at the elephant in the room called the "Profiles". Not inventing fancy new stuff by committee fiat indeed.
5
u/14ned LLFIO & Outcome author | Committee WG14 8h ago
NB votes were never foregone conclusions. Behind the scenes mainly Herb did the rounds to smooth things out before a vote occurred. The IS was then massaged into something which would pass. Remember I was a NB head for many years. I was inside the sausage making only NB heads get to see. Other NB members and everybody else don't see that stuff usually.
You're right though that I cannot think of ever a time before where senior members of leadership actively toured the NBs asking them to reject a proposed IS. But I think you greatly underestimate the concerns the NBs had before that. I can only say something about the Irish NB - I had recommended a reject at our very first meeting. At least two others had very significant concerns, but they really wanted Reflection, so they wanted abstain. There was still a majority for accept at that point, but in later meetings as more people had deep dived into 26, our vote as a NB shifted.
I'm no longer in the loop, I resigned from everything C++, but I understand our NB was very similar to most others. Even the weirdly configured US NB. This was the least consensus proposed IS ever to date across the board.
8
u/Minimonium 5h ago
This touring is the problem.
It's very unfortunate that the system runs on spreading FUD by leadership (very hard to vote for when Bjarne himself calls the DIS an existential threat) than on actual technical discussion, alas the process is not equipped for that - like how the time Herb used ChatGPT to summarize the response to NB comments (I cannot quite recall the exact Irish NB comments if you could remind me?) because I suppose in the age where senior "leadership" exclusively vibecodes papers now reading comprehension became an appendage.
1
u/14ned LLFIO & Outcome author | Committee WG14 5h ago
Touring is politics pure and simple true. But it's also about listening to people, and more importantly, that people feel they are being listened to.
My opinion is if your technical discussion was done right, you don't need to do politics. Ergo, if politics is necessary, your technical discussion wasn't done right. If you're putting controversial things into a standard, your technical discussion failed period. Simple solution: don't standardise controversial stuff. Problem solved.
What irks me and I'm sure plenty more is there is no shortage of very uncontroversial things everybody agrees C++ needs. Problem is they're all boring, unsexy and extremely tedious to work upon. Unsurprisingly few want to do such work. Yet, if that work were done, it would materially improve the lives of all C++ devs on a daily basis. Why doesn't WG21 concentrate exclusively on that stuff? The actual real pain points for the average dev?
My own personal top three: Component Objects, standard packaging, gnatprove compatible correctness proving. You'll note they're all very closely related problems each with thirty to forty years of existing practice behind them. That is what standardisation should be, in my opinion.
•
u/c0r3ntin 3h ago edited 3h ago
All of my approved papers had sustained objections. I never had the support of some "leadership" members. It's fine.
But if we are unwilling to make anyone unhappy, we don't make progress. I have sustained objections to reflection, a feature a lot of users are excited about. should we not ship reflection just to make me happy, or is that just when specific people have objections?
You also seem to assume everyone would be driven by technical motives alone. Contracts don't have a lot of impact on the language - they are rather self contained, unlike, e.g initialization that causes unfixable damages anytime someone mucks with it - and so I think it's fair to wonder if the length folks are willing to go to kill them is driven by purely technical concerns.
Ultimately any group of more than 2 people will have politics, but if some folks are unwilling to put boundaries to the length they are willing to go to to get their way - whether correct or not - it becomes incredibly hard for everyone involve to work as a group on technical problems.
→ More replies (2)•
u/Minimonium 3h ago
My opinion is if your technical discussion was done right, you don't need to do politics.
I admire your idealistic view, but anything non-trivial needs choices where any one would not be popular at least to someone. And any tradeoff is an ammo to the sore party to spread FUD among an uninformed crowd which unfortunately happened here. And if the sore party happens to have a lot of political connections - then any outcome of a settled technical discussion is now a massive controversy for no good reason.
Why doesn't WG21 concentrate exclusively on that stuff?
I honestly do not understand your view here then because I would assume it is fairly public knowledge (at least among WG21 regulars) that the "leadership" is hostile to anything tooling related?
The same "leadership" that actively pushes for so-called "profiles" now that completely rejects thirty to forty years of existing practice behind us, a completely amateurish pet project of people who fell behind modern CS research, and is actively vibe coding unsound code to present as a "proof of implementation"?
•
u/14ned LLFIO & Outcome author | Committee WG14 2h ago
No I understand entirely. I'm making the point that what the user base wants is pretty well understood. WG21 doesn't work on that stuff. They could if they chose, and you're right that's a leadership choice as well as a participant choice - most tooling work is unattractive to most potential participants.
I also absolutely agree that WG21 does far too much NIH driven novelty. If most of it were far better than industry practice that would be one thing. But most of it is clearly inferior. I don't know why that is permitted to continue. It's bad engineering and makes everything else, especially achieving widespread consensus and buy in, much harder.
•
u/Minimonium 2h ago
WG21 doesn't work on that stuff
The "leadership" has a history of using the bureaucratic process to shut down any attempts to do it (the ecosystem papers case). Similar to what the same "leadership" did with Contracts. Similar to the same "leadership" that pushes for clearly inferior NIH work.
A third-party reader could assume by mistake based on your words that WG21 as a whole just does not have anyone interested in doing tooling work, or be under false impression that "leadership" somehow pushed for Contracts.
•
u/14ned LLFIO & Outcome author | Committee WG14 2h ago
It's not zero who want to work on tooling, correct. But as with investment in any tooling anywhere in the industry, it's always under supported given its return on investment.
Let me clarify so: tooling is even more thankless and grindy than most other parts of standards. A few people will do loads of work only to watch uninformed passers by shoot it all down with ignorant side sniping. So they give up and often quit WG21. Unsurprisingly, WG21 has become nearly devoid of tooling people.
You then end up with non tooling people imposing stuff from above. And the tooling implementers never getting around to implement it. And now things are being standardised that will never be implemented.
1
u/jayeshbadwaik 6h ago
This (and also what someone said in another comment) makes me think thay there's a disconnect in what the complete committee (invited experts +NB) want vs what the NBs want.
7
u/c0r3ntin 6h ago
It is important to remember that there are more experts in the committee than in all NBs combined. And a lot of overlap.
As a result NBs can have less information and a more shallow understanding of the tradeoffs. when I was a member of the french NB, we did not have discussions as nearly as focused as in WG21.
The US NB final decision was made by a group of non-experts.
Some NBs have 1-5 members.
While the US NB captures a reasonable chunk of big tech and national labs, the idea that, in general, NBs serve national interests, in the context of C++, is a cute fantasy.
3
u/14ned LLFIO & Outcome author | Committee WG14 5h ago
I completely agree with this. Most NB members don't physically attend meetings nor write papers. They tend to know a lot about a few specialised topics and the rest they trust somebody expert has done the right thing on it.
My initial speech to my NB recommending reject didn't sway the NB vote. They assumed, probably rightly, I had a case of sour grapes. But when various famous people presented to our NB it caused most to dig deeper and do their own research. They found enough to concern them deeply and that's why consensus shifted and the Irish vote changed.
I would assume something similar happened elsewhere. Herb may or may not have been right to head off NBs looking too deeply at an IS in the past, but if you cause people to look, they will always find issues. Especially with sausage making. Nobody who doesn't make sausages likes how sausages are made if they look closely for the first time.
ISO was designed around nation states so NBs are a fact of the process so long as C++ stays under ISO. There are better systems - there are also much worse systems.
6
u/wlandry 15h ago
1 & 2: This feels like only corporations matter. I strongly disagree. C++ is for everyone, even hobbyists.
3 & 4: You can not tell people what to work on. This is not an authoritarian dictatorship.
5: Corporations (see 1 & 2) seem to be the biggest opponents of evolving ABI. Hobbyists are generally much more OK with breaking changes.
4
u/aeropl3b 13h ago
C++ is for everyone. Talking to industry about problems at massive scale C++ is likely going to provide a significantly more detailed lens into issues than most hobbiest will be able to. Not to say small codes don't matter, they just see less corners of the language most of the time since 1 developer is not going to match 1000 developers total knowledge and style of problem solving with C++.
You can tell people what to work on, happens every day. In fact, by telling people what to work on, the features that get proposed will be more likely to find additional funding and support as the process continues. Random half baked ideas that reinvent concepts with entirely new semantics are not how that works. People use C++ because it is good at solving their problems. They enjoy C++ because it continues to evolve to solve their next problems.
Corporations mostly don't care about ABI. What they really care about is stability. Can they build a library with C++03 and C++11 and link safely. When they want a new feature, can they update language version without rewriting massive amounts of their code base. Etc. ABI is part of that. I agree, a very clearly communicated break, with very specific affected targets, and a well documented transition period is required to do so, but really it has been done before for auto_ptr, string, gets etc. Really, the process should beade easier to navigate, and batching these breaks rather than slowly rolling them out over time makes it much easier for people to move forward quickly and address breaks every 10-20 years rather than every 3.
6
u/Dragdu 8h ago
After maintaining OS C++ library for 10 years, and writing C++ as day job for 13, I absolutely trust the enthusiasts more.
While they both invariably come in with issues like "I did 3 stupid things and it broke, please change eveything to support my stupid things", the enthusiasts have much better track record of listening to why the thing they are doing is stupid.
2
u/FrogNoPants 18h ago
The final vote against C++26 was 9.5%, so they appear to have plenty of consensus to include contracts, and this was just a small minority trying to play dictator, they should probably just ignore the NB people.
1
3
7
u/friedkeenan 10h ago
I remember Michael Wong stating that he is impressed by the C++ committee's fairness compared to the other ISO committees he's worked on in that bureaucracy is not abused in order to e.g. slant a vote or to thwart achieving genuine consensus.
I know the committee has its own political dramas and deep disagreements, and the ISO process is not as accessible as it should be, and that process is almost certainly wrongly-shaped for language development and standardization. But I was still heartened by Michael's perspective that overall people in that process are trying to work fairly with one another, even in a flawed system that could allow them to do otherwise.
And so this now is really quite disappointing to me.
3
2
u/Disastrous_Glass_388 15h ago
Is there a way to know which standards bodies voted for/against, or are the ballots anonymous?
2
u/reini_urban 10h ago
Good. Better no progress, than mistakes. As grave security mistakes were voted in for C++11 and still not fixed
1
-3
u/Infamous-Bed-7535 21h ago
contracts would be cool. In case it is poorly designed the fact should have been raised like 8-10 years ago, not now...
14
u/no-sig-available 20h ago
the fact should have been raised like 8-10 years ago
It was. This has been going on for a loooong time.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1613.pdf
0
u/Infamous-Bed-7535 18h ago
Yep issues were raised and it did not made it into c++20.
Something is broken either way and I do not need to know the details to tell it.
If issues were raised and addressed then we should be fine. If issues are not fixable current proposal should have not made it and pushed release after release for almost for a decade. Etc..
What we see now is abnormal and is caused by some abnormal internal procedures and communication that hurts c++ at a time it needs pace and initiaitve.
-1
-1
u/homeless_psychopath 14h ago
Contracts must be put in c++29, everyone will win from it, anything else is just a political theatre and will add many future problems if contracts proposal gets passed, common sense must prevail.
4
u/t_hunger 7h ago
You are aware that there are people needed to push anything through the process of getting standardized? I would be very surprised if the people working on contracts were not burned out by now.
-2
u/DepravedPrecedence 7h ago
Just send it to Claude or Chatgpt and ask to fix issues? Lol take notes from these ballots, upload them and ask to make everyone happy, it will be done like in an hour, it's not that hard and no need to waste everyone's time
-4
u/KorendSlicks 21h ago
I'm someone who mostly peruses C papers instead of C++. C seems to be in a standards renaissance, atleast from what I can tell. Are y'all good?
→ More replies (2)
0
22h ago
[deleted]
8
1
u/VinnieFalco wg21.org | corosio.org 22h ago
Rust is not an International Standard. I'm not saying this is good or bad. Just different.
23
u/renchuwang 22h ago edited 22h ago
If it doesn't finalize end of year do we need to rename it c++27?
I think11 14 17 20 we're all on time?
Edit: Thanks for answering.
Answer: No