As a member of one the objecting NBs (Finland), I think the problems here are far more complex than what this post addresses.

I've not been in the committee as long as Andreas has, but I've been trying to dig through historics as things have unfolded.

I think there are multiple causes, some of which are a decade old by now, why we ended up in this clusterfuck we are in. And yes, our NB voted knowing this clusterfuck might be the end result, even though it didn't seem probable to me (though I knew it was possible).

Am I happy we're in this mess? No. I don't think anyone in the WG21 is.

But I also think WG21 tends to forget that even though we call it "The C++ Committee", it is not an official ISO committee. We are a working group that presents the standard draft to the actual programming languages committee, that is SC22. A good bunch of WG21 members seem to forget this way too often. And a good bunch of them seem to just not have read the ISO code of conduct or rules altogether.

And the situation is not helped by a few individuals in the committee that basically shitpost misinformed or opinions why NBs did what they did based on WG21-internal rumours. And yes, there are ~200 active and around 500 in total WG21 members, so we are not going to avoid rumours.

There's a lot to unpack. From my point of view this divide started from how the ANSI/INCITS (the US NB) in 2014 changed from "one-company-one-vote" to "everyone votes individually" and how that effects the measured difference between WG21-internal polls and NB opinions. Even though that was what ISO wanted, as we are supposed to be individual experts inside WG21. But ISO also wants the NBs to have the final say, as NBs work as checks and balances from its perspective. From my understanding, WG21 used to have these checks and balances in the "one-company-one-vote" -rule, but since that is now gone, those have moved to the NB level. Which is what we see here. This has changed gauging the NB consensus inside the WG21 and made our internal polls less informative towards that direction. And it's a very small gradual change that comes from people following the systems without any greater purpose one way or an another.

I need to say that the above paragraph is just how I see it, but I'd love to know whether more WG21 members feel the same or can debunk it if I'm wrong.

Normally, my articles are technically focused and free of personal opinion. Regarding the rejected DIS, I can only say that I consider it a massive disaster and feel sorry for the entire C++ community.

I disagree with this. Sure, this is a blow to WG21, and a major shakeup there. But there are people who claim they saw this coming a full decade ago, just not sure when. If it wasn't for contracts, it would've been something else. And I have little reason to doubt them from what I've witnessed. And if that is the case, this needed to happen, and it might be better that it happened now than with greater consequences later on.

Saying it's a massive disaster for the entire C++ community, I don't buy. That said, I am sorry to those people who are hit by this, and I view this as a failure of the group I am a member of, and maybe I should've been more outspoken earlier, but I don't know if my voice would've been just one more cook in the entire mess, and I never will.

Regardless of whether someone likes Contracts, considers them important, or sees major weaknesses in them, the topic has been worked on for years and has received a majority vote multiple times in its current form. By voting “no,” an established system, one based primarily on trust and respectful collaboration, has been shaken.

This part is not really even an opinion, it's just true. Though how established that system truly was in reality is up for debate.

Every ISO standard is simply a set of compromises. Everyone loses sometimes, and everyone wins sometimes. Overall, the result is one in which all participants have given their best. During the DIS vote, the losing parties refused to accept their loss.

This is what I most vehemently disagree with. Making an international standard is not about winning or losing. And if NB comments are not acted on, even if they are heard, there is very little reason to those NBs to change their vote. As WG21, we, unlike in most previous cases, but using the same process as previously, gambled that the dissenting voices were not numerous enough to vote down the DIS. That gamble did not pay off and now we're here.

The reality I see from historical notes and the current situation here is that WG21 has changed both in composition and how seriously it has taken the NB votes. Our processes have not kept up with the changes, and this is the end result.

The question that primarily determines how to move forward is whether the group can rebuild trust.

100% agree on this one.

I found the article highly sensationalist, opinionated, guilt-planting and clickbaity.

Andreas is complaining, basically, that people who were con to Contracts raised their issues, where they detailed that Contracts was ill-defined / insufficient / bad / problematic(TM) or whatever; they were rejected... and then things simply continued to the next available phase, where people were allowed to vote. And they voted No. Because they had issues. At no point were the con people "refusing to accept their loss" as Andreas words it, the voting process was still legally ongoing.

Like, what was Andreas expecting? That the con people betrayed themselves and surrendered themselves before the voting phase was reached? Consider: that's how we got stuck with stuff like std::random.

IMHO Andreas managed to summarize this clown car crash way more constructively than I could. Kudos to that.

C++ is cancelled

How does it correlate with ai psychosis? Do the national bodies lost interest or contracts is a too controversial topic?

anyone who surrenders to Trumpism and its associated modern Mc-Carthyism-like demands

I didn't catch this part, how is that related to the topic? Edit: or how it relates to the rest of your post

p4334

The P2900 contracts and extensions aim to change the nature of C++ and are an existential threat to C++, adding complexity and bloat (~56 pages in the draft standard for an incomplete version), potential overheads, and novel opportunities for errors without addressing the current community and regulatory body demands for guarantees (e.g., https://docbox.etsi.org/CYBER/CYBER/Open/ETSI_TS_104_198_DRAFT.zip presents C++ as providing no memory safety guarantees).

(emphasis mine)

Honestly I think this is by far the largest mistake that has led to the current C++ situation: listening to things like the corporate Rust party line and the Rust community (who also have the unveiled interest of replacing GPL-like code and licenses with corporate-friendly ones that allows wealth to steal projects from skill, see eg.: Ubuntu), instead of examining what's on the field, what's on the mind, and accepting that the way C++ functions is intrinsically different than a language that only provides you the tools to let you do what the makers want to let you do. Because the truth is, C++ does provide memory safety guarantees, it just puts them at a lower level of mandate than the mandate that you can make the code do (mostly) what you want rather than only what the Party line allows.

Not to mention, in this day and age anyone who surrenders to Trumpism and its associated modern Mc-Carthyism-like demands is ethically too compromised to be trustable in a field.

Mainly P2900 Contracts’ fundamental flaws

Also Contract concerns and where they are addressed

This makes me wonder what we're the arguments against, is there a read about why NBs were opposed?

Edit: Found an answer by Harald Achitz in comments to the post, but that's a lot to read, it seems:

it's not just one paper, but rather a whole book. Thats the problem.

As an entry point, I recommend:

Procedural problems: P4381 (https://wg21.link/P4381)

Technical problems: P4334 (https://wg21.link/P4334)

Both papers reference plenty of other papers, so they provide a good starting point for getting an overview.

This blog series by Mateusz Pusz also provides an excellent overview of the topic: https://train-it.eu/blog/series/cpp26-contracts/

My personal favorite topics, the problems for binary package management and the growing number of implementation-defined aspects introduced by contracts are actually not covered exhaustively by any of these sources. (imho) The response to the technical concerns about build systems and package management was essentially: Nothing new here. The situation is already a mess, so we're just adding more mess. Literally!

What this means is:

WG21, what we usually call "the C++ committee" is the working group that prepares the C++ draft to the actual ISO committee, that is SC22, that approves the standard.

In WG21, people vote (or poll, really) as individual experts, who are members of one national board or an another. WG21 decided to send a draft to SC22 with knowledge that multiple national bodies (NBs) would object, it wasn't exactly a secret to anyone.

Then, in the ratification of the actual standard, it is NBs from different countries that actually vote. These are usually the same people who take part in WG21 work, though NBs can decide by themselves how they choose their vote.

In my national board, majority was against, with zero objections, so our NB chose to be one of the 9 countries who voted against. I do not know how other national boards work out their vote, but AFAIK most of them also have internal vote for that. This is how international standards committees are supposed to work, as to not have any country or entity push a standard that doesn't have clear consensus. There are varying opinions if that suits programming language development or not, and I'm not interested in that debate.

For the standard to be ratified, it needs both 2/3s majority in favour, and no more than 1/4th objecting. Now the SC22 vote failed on both counts, which pretty much means there isn't going to be C++26. We don't have time in the committee to get it approved in 2026 anymore.

I have my own thoughts about why we went from "zero objections ever" to failing both requirements. And even if I was part of the objecting votes, I hardly consider the result of having disapproved ballot a good outcome. It shouldn't have ever gotten to the point where that was even an option.

And here I was hoping that C++ would add std::ballot as an alternative to the whole std::random debacle.

Balloting for C++26 as a whole. WG21 ("the committee") has finished the technical work on C++26 in March this year, but it wasn't formally approved by ISO (that approval was supposed to be this ballot). So WG21 will now have to figure out how C++26 can be changed, so that it will be approved by ISO (National Bodies).

P-members are ISO participating members, and O-members are ISO observing members.

Sorry if I'm too dumb but:

• balloting for what? the whole C++26, or a subset like contracts?
• also why ballot for a version that is supposedly the current one? shouldn't they handle versions like 29 or 32?
• what are P-members compared to members?

This post is as confusing as the C++ standard itself.

Edit: Thank you all (especially cmeerw and Robert) for your explanations, I'm really rusty when it comes to all the C++ versions and committees.

I'm not a game dev but work in a scientific field. One thing I didn't see mentioned here which may or may not be relevant is it pays to try to keep your memory footprint as low as possible. Memory I/O is a bitch. So for example, let's say you have 2 vectors that interact in some way. You may be tempted to store precalculated interactions in a matrix, but generally speaking, it's best not to do this. Just calculate each cell of the matrix on the fly as you need it, even if it's a long formula and you need to access this same value many times. 2 vectors are more likely to fit in L1 cache and you'll get the best performance out of all the compiler optimizations. It makes a huge difference.

Are you looking for a critique on the code, or tips on how you might improve it?

I think you need to enclose your code block in triple back quotes to make it render properly in markdown. I've tried to fix it up a bit.

template <typename T, const int length=5> 
class vector {  
  public:  
    T v[length];  
    vector operator +(const vector &obj) {  
        vector tmp;  
        for(int i = 0; i < length; i++)  
            tmp.v[i] = v[i] + obj.v[i];  
        return tmp;  
        /* This method below only works if length is a fixed size return  
            {v[0] + obj.v[0], v[1] + obj.v[1], v[2] + obj.v[2], v[3] + obj.v[3], v[4] + obj.v[4]};*/ 
    } 
};  

int main() {  
    vector<int> a={1,2,3,4,5}; vector<int> b={1,2,3,4,5};  

    auto c = a + b;  

    std::cout << "(int) ";  
    for(int i = 0; i < 5; i++)  
        std::cout << c.v[i] << " ";  
    std::cout << std::endl;  
}  

A great read. It's wacky how the compiler can simply fallthrough to next linked statement. Anways glad to see these cases being defined now.

I don't find Microsoft in the link you posted, but given the state of visual studio, it's understandable

https://edg.com/c goes into a bit more details of what it is. You might actually have used it without realising it (for example, IntelliSense in Visual Studio is based on the EDG front end). Some of the companies using the EDG front end are listed on https://edg.com/customers (but some other users are not listed there).

Seems like this is alleged to be a program that translates from one source language to another source language.

Documentation is a story book.

I've not heard of this before and the website didn't help with "what" and "why". What is this? Did anyone here use this, and what was your experience?

One more lie to be added to (LTS / non-"latest commit") C++...

Move doesn't move, forward doesn't forward, (variadic list of failures...), infinite loops don't.

Interesting read! I work on CAD automation, and I can see std::hive being useful for an interactive BOM editor where parts are frequently added or removed while other components hold references to the remaining records. I’d be curious to benchmark it against std::vector and std::list for that workload.

Damn that hits.

Move doesn't move, forward doesn't forward, vector is aimless, const doesn't, inline doesn't, static is quite dynamic, [[nodiscard]] is discarded, and you still need to noexcept(noexcept( body_of_function )) explicit(explicit( body_of_function )) { body_of_function } -> decltype(body_of_function) the body of your lambdas to have the correct return type... Honestly by this point I just use a macro.

I may as well be forgiven for hoping, in my deep true self, that hive at least brings in some bees to C++26... but no, it probably bring in zombies or something.

In this day an age it's difficult to know what lies more: the Bible or the C++ Standard. And I'm not sure if that is a compliment in either direction. Aimless, one would say: just as vector.

The two last code examples are identical, which would seem to be a mistake