The result of the C++26 DIS ballot

xiaoyu2006

I can only describe current C++ as a Frankenstein. Trying to introduce modern features while having to keep compatibility is just really hard and probably not "the right way".

BonusPlay

C++ has lost touch with reality a few years ago. Modules, a feature 6 years old still only have partial support [1] and are nowhere to be seen in practical use. Good luck finding g a C++ library using modules. This may be similar to Java vs Kotlin race, where Kotlin added improvements, while Java was still stuck in 1.8. The answer was to add as many features to the language as possible. Looks a bit like C++ is starting to do the same. [1] https://en.cppreference.com/cpp/compiler_support

weinzierl

The simplified TLDR is that ISO for the very first time did not approve a proposed C++ standard. 9 out of 22 countries voted "no" , six would have been enough. These were Denmark, Finland, Iran, Italy, Japan, Luxembourg, Romania, Spain, and Sweden. In a addition and independently only 12 of the 20 participating members approved when 14 were needed. The dispute is most likely because of a single feature called "contracts" . Very simplified these are conditions placed in a function's signature that are supposed to be checked at runtime. The proposed implementation of this feature has been controversial from the start with prominent members of the community (Bjarne Stroustrup amongst them) expressing concerns.

chiharukiryu

Old king is still fighting but rust is just more properly for agent powered missions

groos

C++ is probably the largest, most complex programming language to ever exist. I, as a former C++ compiler developer, find it hard to keep up with the language changes. What chance does an average user have?

rfgplk

The C++ committee is pointless, and this is coming from a C++ expert. Most of the things the committee has been "working on" are realistically _side projects_ today with AI. I've made countless additions to my clang fork the most notable being a source compatible borrow checker, ie you turn it on and it tells you where you effed up. Zero source changes. Equally as correct as Rust. For any sane C++ program. The committee still isn't capable of implementing this btw.

zombot

What does "DIS" mean?

qalmakka

IMHO the current contracts are a half-baked feature that I suspect will immediately end up in most coding styles as "do not use contracts". I understand the concept but having a feature that's not consistent among compilers, targets, ... all while doing absolutely nothing to solve the _real_ problems with C++. Like that the build model is still the obsolete TU model of C, while adding multiple compile-time features that inevitably end up causing build times to skyrocket considerably. Or that modules are still DOA after 6 years. Or that the syntax is full of bullshit anti-features that could be at least fixed by having a proper build model (like Rust) and editions (like Rust). Having yet another feature that only works sometimes with quirky semantics is dumb and I understand why many people feel like it should be shelved to prioritise the features people _really_ care about, like meta

rurban

This contracts design is good, opposed to Gudstedt's variant with the semicolon. Because here it is trivial to make them backwards compatible, by just using a PRE() and POST() macro which are empty pre-C++26. The contracts_assert is either static or runtime, which the compiler can decide. Better than explicit static/asserts, which are either unnecessary or costly.

koe123

What a mess. Can anyone give me a bull-case for why you would ever pick C++ for a new project?

code_biologist

Went looking on reddit and other places for a good, non-political explanation of what's going on. Didn't find that, but I did find this good critique of contracts by david_chisnall: https://lobste.rs/s/rlrfew/balloting_has_completed_for_c_26#...

whizzter

Oh my, here I'm looking like a fool, literally gave a talk on the new <meta>/Reflection feature on Thursday and doing it assumed that it was more or less a lock (Well I guess the refl feature will come out if contracts can be dumped and the standard gets out even if it won't technically be in C++26 anymore :P ) The reflection feature is good, I would've settled for less but there's some pretty cool stuff enabled by it. - direct to struct JSON parsing with property-name aliasing via annotations - field creation/renaming, I've made a make_named<"a","b">(1,"hello") to create an object with fields named a and b (think of std::make_tuple on steroids) - I'm basically halfway done with a DB abstraction that can be used similarly to C#'s Linq. struct [[=sql26::name("posts")]] post { int id; std::string name; }; dbcontext<post> dbctx; for(auto post:dbctx.posts.where([](auto post) { return post.id>100; }) { ... } ^- in the above example the template inclusion of post creates the posts-field in the context, the where predicate lambda gets a decorated variant of the post type members that are then deferred until execution (starting iterating the itererable). It's dangerously powerful though since all of this is enabled by consteval, so any IDE support will need to be running the consteval code continiously in these scenarios to update type-info before being able to do code completion (even if people are probably way into LLM's to bother anymore?). The talk isn't online yet since they haven't had time to edit the videos. The JSON and make_named example/code can be found in my repo, haven't pushed the SQL feature yet as I'm not happy with some other parts of the API surface yet (aggregation is hard to express/translate compactly and unambigiously). https://github.com/whizzter/ret26

feverzsj

Isn't it kinda ... obvious? It may not be as bad as modules/reflection/std::range/std::execution, but it's still a bag of UB shits.

ho_schi

Why I have the gut feeling, that this is good for us? Not saying I understand contracts at all. I read about contracts being complex and adding implementation defined behavior . I don’t want that! C++ needs #secure and #insecure built-in. Kill all undefined-behavior and minimize implementation behavior. Maybe add new library types with default safety. Put the unfixable stuff behind #insecure . I see immediate benefits of things added in C+11, C++14 and C++17. Basically they made it safer and less error-prone.