C++26 is done: ISO C++ standards meeting Trip Report

https://herbsutter.com/2026/03/29/c26-is-done-trip-report-march-2026-iso-c-standards-meeting-london-croydon-uk/

by pjmlp • 4 months ago

314 417 4 months ago

Biggest open question is whether the small changes to the module system in this standard will actually lead to more widespread adoption

forrestthewoods4• 4 months ago

No. Modules are a failed idea. Really really hard for me to see them becoming mainstream at this point.

m-schuetz4• 4 months ago

The idea is great, the execution is terrible. In JS, modules were instantly popular because they were easy to use, added a lot of benefit, and support in browsers and the ecoysystem was fairly good after a couple of years. In C++, support is still bad, 6 years after they were introduced.

Xraider72• 4 months ago

No idea if modules themselves are failed or no, but if c++ wants to keep fighting for developer mindshare, it must make something resembling modules work and figure out package management.

yes you have CPM, vcpkg and conan, but those are not really standard and there is friction involved in getting it work.

AyanamiKaine2• 4 months ago

Can you explain why you think modules are a failed idea? Because not that many use them right now?

Personally I use them in new projects using XMake and it just works.

zarzavat2• 4 months ago

The best thing the C++ WG could do is to spend an entire release cycle working on modules and packaging.

It's nice to have new features, but what is really killing C++ is Cargo. I don't think a new generation of developers are going to be inspired to learn a language where you can't simply `cargo add` whatever you need and instead have to go through hell to use a dependency.

luka598• 4 months ago

Agreed, arcane cmake configs and or bash build scripts are genuinely off-putting. Also cpp "equivalents" of cargo which afaik are conan and vcpkg are not default and required much more configuring in comparison with cargo. Atleast this was my experience few years ago.

groundzeros2015• 4 months ago

I didn’t think header only was that bad - now we have a nightmare of incompatible standards and compilers.

mgaunard15• 4 months ago

In my experience, no one does build systems right; Cargo included.

The standard was initially meant to standardize existing practice. There is no good existing practice. Very large institutions depending heavily on C++ systematically fail to manage the build properly despite large amounts of third party licenses and dedicated build teams.

With AI, how you build and integrate together fragmented code bases is even more important, but someone has yet to design a real industry-wide solution.

ho_schi• 4 months ago

I’m still surprised how people ignore Meson. Please test it :)

https://mesonbuild.com/

And Mesons awesome dependency handling:

https://mesonbuild.com/Dependencies.html

https://mesonbuild.com/Using-the-WrapDB.html#using-the-wrapd...

https://nibblestew.blogspot.com/2026/02/c-and-c-dependencies...

I suffered with Java from Any, Maven and Gradle (the oldest is the the best). After reading about GNU Autotools I was wondering why the C/C++ folks still suffer? Right at that time Meson appeared and I skipped the suffering.

    * No XML
    * Simple to read and understand
    * Simple to manage dependencies
    * Simple to use options

Feel free to extend WrapDB.

saghm6• 4 months ago

To me, the most important feature of Cargo isn't even the dependency management but that I don't ever need to tell it which files to compile or where to find them. The fact that it knows to look for lib.rs or main.rs in src and then recursively find all my other modules without me needing to specify targets or anything like that is a killer feature on its own IMO. Over the past couple of years I've tried to clone and build a number of dotnet packages for various things, but for an ecosystem that's supposedly cross-platform, almost none of them seem to just work by default when I run `dotnet build` and instead require at least some fixes in the various project files. I don't think I've ever had an issue with a Rust project, and it's hard not to feel like a big part of that is because there's not really much configuration to be done. The list of dependencies is just about the only thing in there that effects the default build; if there's any other configuration other than that and the basic metadata like the name, the repo link, the license, etc., it almost always will end up being specifically for alternate builds (like extra options for release builds, alternate features that can be compiled in, etc.).

daemin3• 4 months ago

I may be in the minority but I like that C++ has multiple package managers, as you can use whichever one best fits your use case, or none at all if your code is simple enough.

It's the same with compilers, there's not one single implementation which is the compiler, and the ecosystem of compilers makes things more interesting.

pjmlp12• 4 months ago

It is already there, with vcpkg and conan, alongside cmake.

You cannot cargo add Unreal, LLVM, GCC, CUDA,...

superxpro122• 4 months ago

100% agree this is something that would have immediate, high value impact.

The fact that building C++ is this opaque process defined in 15 different ways via make, autoconf, automake, cmake, ninja, with 50 other toolchains is something that continues to create a barrier to entry.

I still remember the horrors of trying to compile c++ in 2004 on windows without anything besides borland...

Standardizing the build system and toolchain needs to happen. It's a hard problem that needs to be solved.

jjmarr9• 4 months ago

No, because most major compilers don't support header units, much less standard library header units from C++26.

What'll spur adoption is cmake adopting Clang's two-step compilation model that increases performance.

At that point every project will migrate overnight for the huge build time impact since it'll avoid redundant preprocessing. Right now, the loss of parallelism ruins adoption too much.

dheera• 4 months ago

I frankly wish we'd stop developing C++. It's so hard to keep track of all the new unnecessary toys they're adding to it. I thought I knew C++ until I read some recent C++ code. That's how bad it is.

Meanwhile C++ build system is an abomination. Header files should be unnecessary.

ranger_danger• 4 months ago

You don't have to keep up with or use any of the new features. I still pay my bills writing C++98 and have no desire to use a higher version.

LatencyKills• 4 months ago

This is awesome. I've was a dev on the C++ team at MS in the 90s and was sure that RTTI was the closest the language would ever get to having a true reflection system.

rustyhancock2• 4 months ago

I look forwards to getting to make use of this in 2040!

Proper reflection is exciting.

bigbuppo2• 4 months ago

GCC has it marked as 'RESOLVED FIXED' as of about a week and a half ago. So, it's coming.

Also, useful: https://gcc.gnu.org/projects/cxx-status.html

rustyhancock2• 4 months ago

Support in GCC isn't what limits my usage of latest C++ at work.

affenape2• 4 months ago

Finally, reflection has arrived, five years after I last touched a line in c++. I wonder how long would it take the committee, if ever, to introduce destructing move.

IshKebab• 4 months ago

Yeah I feel the same way. Lots of nice features that would have been helpful 5 years ago before I switched to Rust.

72deluxe6• 4 months ago

What do you mean by a destructing move? Are you trying to avoid use of a moved object after you've moved it?

eg. B = std::move(A); // You are worried about touching A when it's in this indeterminate state?

yolina4• 4 months ago

destructive moves are required to make moves zero cost.

Currently move semantics in C++ requires that A is left in a 'moved from, but valid state' which means that:

1. The compiler must still generate code that calls the destructor.

2. Every destructor need have to have some flag and a test in it like: if(moved_from) // do nothing else { free_resources(); }

(Granted, for some simple types the compiler might inline and removed redundant checks so it ends up with no extra code, but that is not guaranteed)

With destructive moves the compiler can just forget about the object completely, no need to call it, destructurs can be written as normal and only care about the invariants established in the constructor.

jandrewrogers11• 4 months ago

C++26 adds destructive moves. They are called relocatable types.

There are edge cases where destructive moves are not safe and it is impossible for the compiler to know they aren't safe. C++ uses non-destructive moves when it can't prove the safety of destructive moves, even if destructive moves may in fact be safe. C++26 adds a type annotation that guarantees destructive moves are safe in cases where you can't prove they are un-safe.

The concept of relocatable types is actually a bit broader in scope than just destructive moves, but destructive moves are one of the things it enables. It is a welcome change.

aw162110716• 4 months ago

C++26 adds destructive moves. They are called relocatable types.

I thought those were removed? For example, see Herb's 2025-11/Kona trip report [0]:

For trivial relocatability, we found a showstopper bug that the group decided could not be fixed in time for C++26, so the strong consensus was to remove this feature from C++26.

[0] https://herbsutter.com/2025/11/10/trip-report-november-2025-...

affenape2• 4 months ago

From the proposal, I see a bunch of new keywords and rules - alright given the language's heritage. But what happens if I "relocate" a variable value - would a "shell" remain or how exactly C++ is supposed to handle this:

  auto value = create_value();
  if (some_cond) {
    consume_value(std::move(value)); // not sure whether it's move here, but I guess my point is clear
  }

  use_value(value);

levodelellis• 4 months ago

Great. C++20 has been my favorite and I was wasn't sure what the standards says since it's been a while. I'll be reading the C++26 standard soon

suby• 4 months ago

I am somewhat dismayed that contracts were accepted. It feels like piling on ever more complexity to a language which has already surpassed its complexity budget, and given that the feature comes with its own set of footguns I'm not sure that it is justified.

Here's a quote from Bjarne,

So go back about one year, and we could vote about it before it got into the standard, and some of us voted no. Now we have a much harder problem. This is part of the standard proposal. Do we vote against the standard because there is a feature we think is bad? Because I think this one is bad. And that is a much harder problem. People vote yes because they think: "Oh we are getting a lot of good things out of this.", and they are right. We are also getting a lot of complexity and a lot of bad things. And this proposal, in my opinion is bloated committee design and also incomplete.

addaon3• 4 months ago

I can’t speak to the C++ contract design — it’s possible bad choices were made. But contracts in general are absolutely exactly what C++ needs for the next step of its evolution. Programming languages used for correct-by-design software (Ada, C++, Rust) need to enable deep integration with proof assistants to allow showing arbitrary properties statically instead of via testing, and contracts are /the/ key part of that — see e.g. Ada Spark.

StilesCrisis3• 4 months ago

Right, I think the tension here is that we would like contracts to exist in the language, but the current design isn't what it needs to be, and once it's standardized, it's extremely hard to fix.

bluGill12• 4 months ago

The people who did contracts are aware of ada/spark and some have experience using it. Only time will tell if it works in c++ but they at least did all they could to give it a chance.

Note that this is not the end of contrats. This is a minimun viable start that they intend to add to but the missing parts are more complex.

derriz• 4 months ago

C++ is the last language I'd add to any list of languages used for correct-by-design - it's underspecified in terms of semantics with huge areas of UB and IB. Given its vast complexity - at every level from the pre-processor to template meta-programming and concepts, I simply can't imagine any formal denotational definition of the language ever being developed. And without a formal semantics for the language, you cannot even start to think about proof of correctness.

steveklabnik5• 4 months ago

The devil is in the details, because standardization work is all about details.

From my outside vantage point, there seems to be a few different camps about what is desired for contracts to even be. The conflict between those groups is why this feature has been contentious for... a decade now?

Some of the pushback against this form of contracts is from people who desire contracts, but don't think that this design is the one that they want.

quotemstr• 4 months ago

But why? You can do everything contracts do in your own code, yes? Why make it a language feature? I'm not against growing the language, but I don't see the necessity of this specific feature having new syntax.

wpollock2• 4 months ago

Programming languages used for correct-by-design software (Ada, C++, Rust) ...

A shoutout to Eiffel, the first "modern" (circa 1985) language to incorporate Design by Contract. Well done Bertrand Meyer!

kajaktum• 4 months ago

C++ needs to give itself up and make way for other, newer, modern, language that have far, far fewer baggage. It should be working with other language to provide tools for interop and migration.

C++ will never, ever be modern and comprehensible because of 1 and 1 reason alone: backward compatibility.

It does not matter what version of C++ you are using, you are still using C with classes.

ozgrakkurt9• 4 months ago

I don’t understand this “next evolution” approach to language design.

It should be done at some point. People can always develop languages with more or less things but piling more things on is just not that useful.

It sounds cool in the minds of people that are designing these things but it is just not that useful. Rust is in the same situation of adding endless crap that is just not that useful.

Specifically about this feature, people can just use asserts. Piling things onto the type system of C++ is never going to be that useful since it is not designed to be a type system like Rust's type system. Any improvement gained is not worth piling on more things.

Feels like people that push stuff do it because "it is just what they do".

Sharlin• 4 months ago

Problem is contracts mean different things to different people, and that leads standard contracts support being a compromise that makes nobody happy. To some people contracts are something checked at runtime in debug mode and ignored in release mode. To others they’re something rigorous enough to be usable in formal verification. But the latter essentially requires a completely new C++ dialect for writing contract assertions that has no UB, no side effects, and so on. And that’s still not enough as long as C++ itself is completely underspecified.

raincole• 4 months ago

I mean... it's C++. The complexity budget is like the US government's debt ceiling.

Maxatar• 4 months ago

Without a significant amount of needed context that quote just sounds like some awkward rambling.

Also almost every feature added to C++ adds a great deal of complexity, everything from modules, concepts, ranges, coroutines... I mean it's been 6 years since these have been standardized and all the main compilers still have major issues in terms of bugs and quality of implementation issues.

I can hardly think of any major feature added to the language that didn't introduce a great deal of footguns, unintended consequences, significant compilation performance issues... to single out contracts is unusual to say the least.

jibal• 4 months ago

It doesn't sound that way to me, but there's a lot of context at https://youtu.be/tzXu5KZGMJk?t=3160

jandrewrogers11• 4 months ago

C++ contracts standardizes what people already do in C++. Where is the complexity in that? It removes the need to write your own implementation because the language provides a standard interoperable one.

An argument can be made that C++26 features like reflection add complexity but I don't follow that argument for contracts.

ghosty141• 4 months ago

The quote of Bjarne is a bit out of context. It was made after an hour long talk about the pitfalls and problems of contracts in c++26: https://youtu.be/tzXu5KZGMJk

This should also clarify the complexity issue.

seertaak3• 4 months ago

Can you share what aspects of the design you (and Stroustroup) aren't happy with? Stroustroup has a tendency of being proven right, with 1-3 decade lag.

ghighi78782• 4 months ago

Well thats not always true. Initializer list is a glaring example. So are integer promotion some other things like

tialaramex14• 4 months ago

Certainly we can say that Bjarne will insist he was right decades later. We can't necessarily guess - at the time - what it is he will have "always" believed decades later though.

devnullbrain2• 4 months ago

Source of quote:

https://youtu.be/tzXu5KZGMJk?t=3160

Waterluvian• 4 months ago

Has any project ever tried to quantify a “complexity budget” and stick to it?

I’m fascinated by the concept of deciding how much complexity (to a human) a feature has. And then the political process of deciding what to remove when everyone agrees something new needs to be accepted.

ghighi78782• 4 months ago

Just because Bjarne thinks the feature is bad doesnt mean it is bad. He can be wrong. The point is, most peoppe disagree with him, and so a lot of peoppe do think it is good.

gmueckl• 4 months ago

There have been several talks about contracts and the somewhat hidden complexities in them. C++ contracts are not like what you'd initally expect. Compiler switches can totally alter how contracts behave from getting omitted to reporting failures to aborting the program. There is also an optional global callback for when a contract check fails.

Different TUs can be compiled with different settings for the contract behavior. But can they be binary compatible? In general, no. If a function is declared in-line in a header, the comoiler may have generated two different versions with different contract behaviors, which violates ODR.

What happens if the contract check calls a helper function that throws an exception?

The whole things is really, really complex and I don't assume that I understand it properly. But I can see that there are some valid concerns against the feature as standardized and that makes me side with the opposition here: this was not baked enough yet

DenisM• 4 months ago

to a language which has already surpassed its complexity budget

I've been thinking that way for many years now, but clearly I've been wrong. Perhaps C++ is the one language to which the issue of excess complexity does not apply.

selfmodruntime2• 4 months ago

In essence, a standard committee thinks like bureaucrats. They have little to no incentive to get rid of cruft and only piling on new stuff is rewarded.

zzzoom• 4 months ago

That's a genius idea, keep adding broken stuff into the standard until there's no choice but to break compatibility to fix it.

karmakurtisaani• 4 months ago

No no no, you add new stuff that will totally fix those problems!

WalterBright13• 4 months ago

I implemented Contracts in the C++ language in the early 90's as an extension.

Nobody wanted it.

https://www.digitalmars.com/ctg/contract.html

ChrisGreenHeur• 4 months ago

it could be possible that llms can mak great use of them

mort962• 4 months ago

How do you know nobody wanted it?

locknitpicker2• 4 months ago

Nobody wanted it.

The fact that the C++ standard community has been working on Contracts for nearly a decade is something that by itself automatically refutes your claim.

I understand you want to self-promote, but there is no need to do it at the expense of others. I mean, might it be that your implementation sucked?

Twey2• 4 months ago

I think it's also true that, regardless of the desirability of the feature at the time (which sibling comments discuss eloquently) people who've bought into a language are usually quite wary of also buying into extensions to that language. The very act of ratification by the committee gives this proposal a ‘feature’ that the DMC++ extension lacked in compatibility expectations over time and across implementations — it's not necessarily a comment on the technical quality or desirability of the work itself.

Defletter4• 4 months ago

But then why did you add your contract system to D? You implemented your contract system in the "early 90's", and D was released in 2001, so that's near a decade of "nobody wanted it". So then why add them as a core language feature of a new programming language if no one wanted it? Why is it still a core language feature? And why object to C++ finally adding contracts. I just don't get what you're even arguing here.

raverbashing• 4 months ago

Geez if Bjarne thinks it's

bloated committee design and also incomplete

That's truly in that backdoor alley catching fire

armchairhacker• 4 months ago

I wonder if C++ already has so much complexity, that it would actually be a good idea to ignore feature creep, and implement any feature with even the most remote use-case.

It sounds (and probably is) insane. But if a feature breaks backwards compatibility, or can't be implemented in a way that non-negligibly affects compiler/IDE performance for codebases that ignore it, what's the issue? Specifically, what significant new issues would it cause that C++’s existing bloat hasn’t?

C++20 isn't fully implemented in any one compiler (https://en.cppreference.com/w/cpp/compiler_support.html#C.2B...).

cemdervis• 4 months ago

GCC and MSVC are pretty close. fyi, the tables on cppreference are rather outdated at this point. I made a more up-to-date, community-maintained site: https://cppstat.dev/?conformance=cpp20

mort962• 4 months ago

Contracts are already informally a thing: most functions have preconditions, and if you break those preconditions, the function doesn't make any guarantees of what it does.

We already have some primitive ways to define preconditions, notably the assert macro and the 'restrict' qualifier.

I don't mind a more structured way to define preconditions which can automatically serve as both documentation and debug invariant checks. Though you could argue that a simpler approach would be to "standardize" a convention to use assert() more liberally in the beginning of functions as precondition checks; that a sequence of 'assert's before non-'assert' code should semantically be treated as the functions preconditions by documentation generators etc.

I haven't looked too deep into the design of the actual final contracts feature, maybe it's bad for reasons which have nothing to do with the fundamental idea.

locknitpicker2• 4 months ago

I am somewhat dismayed that contracts were accepted. It feels like piling on ever more complexity to a language which has already surpassed its complexity budget, and given that the feature comes with its own set of footguns I'm not sure that it is justified.

I don't think this opinion is well informed. Contracts are a killer feature that allows implementing static code analysis that covers error handling and verifiable correct state. This comes for free in components you consume in your code.

https://herbsutter.com/2018/07/02/trip-report-summer-iso-c-s...

Asserting that no one wants their code to correctly handle errors is a bold claim.

20k• 4 months ago

Contracts aren't for handling errors. That blog post is extremely out of date, and doesn't reflect the current state of contracts

Modern C++ contracts are being sold as being purely for debugging. You can't rely on contracts like an assert to catch problems, which is an intentional part of the design of contracts

troupo• 4 months ago

So go back about one year, and we could vote about it before it got into the standard, and some of us voted no. Now we have a much harder problem. This is part of the standard proposal.

Offtopic, but this is a problem in the web world, too. Once something is on a standards track, there are almost mechanisms to vote "no, this is bad, we don't need this". The only way is to "champion" a proposal and add fixes to it until people are somewhat reasonably happy and a consensus is reached. (see https://x.com/Rich_Harris/status/1841605646128460111)

randusername• 4 months ago

It feels like piling on ever more complexity to a language which has already surpassed its complexity budget, and given that the feature comes with its own set of footguns I'm not sure that it is justified.

This is a common sentiment about C++, but I find it very interesting that everyone seems to have a different feature in mind when they say it.

estimator7292• 4 months ago

I think that's a clear and unambiguous point in favor of the argument. There are so many hellishly complex things in C++ that the community can't settle on even a small subset to be the worst contender.

Half Life 3 rules apply. Every time someone complains about complexity in C++, the committee adds a new overly complex feature. It remains a problem because complexity keeps getting shoveled on top of the already complex language.

DrBazza• 4 months ago

C++ isn't the first language to do things, but was/is often the first mainstream language to do things.

And then people complain about C++ for doing it wrong, or its complexity, and show language 'X' that does it better/right, but only because they saw C++ do it first, and 'not quite right'.

I expect contracts to be similar - other languages will watch, learn, and do version two, and then complain about c++, etc.

It took 'quite a while' to get rid of auto_ptr, for example.

If it wasn't for the fact this is a language feature, it would be better off in boost where it can be tested in the wild.

btown• 4 months ago

Is there any good documentation about contracts? https://en.cppreference.com/w/cpp/language/contracts.html is incredibly confusing - its first displayed example seems to be an edge case where the assertion itself causes a mutation?

https://en.cppreference.com/w/cpp/language/function.html#Fun... is vaguely better, but still quite dense.

IMO the syntax makes things hard for a newcomer to the syntax to understand, which I see as core to any programming language's goals of community.

    double square_root(double num) asserts_pre(num >= 0)

would have been far more self-evident than just

    double square_root(double num) pre(num >= 0)

But I suppose brevity won out.

steveklabnik5• 4 months ago

I believe that https://isocpp.org/files/papers/P2900R14.pdf is the paper, which doesn't mean it's good documentation, as it's meant for modifying the standard. However, in its early sections, it does link to other papers which have more information, and the "proposed wording" section should be where the standardize lives, with the rest of it being context.

delduca• 4 months ago

Sadly, transparent hash strings for unordered_map are out.

secondcoming• 4 months ago

It is annoying that they didn't just apply this to all containers

porise2• 4 months ago

I don't care until they stop pretending Unicode doesn't exist.

usrnm• 4 months ago

What are you talking about, there is actually too much unicode awareness in C++. Unicode is not the same thing as utf-8. And, frankly, no language does it right, I'm not even sure "right" exists with Unicode

leni5362• 4 months ago

Too much unicode in standard C++? Where?

porise2• 4 months ago

And yet, none of them work with std::regex etc.

dataflow3• 4 months ago

Second, conforming compiler and standard library implementations are coming quickly. Throughout the development of C++26, at any given point both GCC and Clang had already implemented two-thirds of C++26 features. Today, GCC already has reflection and contracts merged in trunk, awaiting release.

How far is Clang on reflection and contracts?

cpeterso• 4 months ago

Clang’s C++2c implementation status page simply says “no” for both reflection and contracts. GCC’s says “yes”.

https://clang.llvm.org/cxx_status.html

https://gcc.gnu.org/projects/cxx-status.html

dataflow3• 4 months ago

That much I'm aware, but that's just about feature availability. I was wondering how far the implementations have progressed internally, despite the features being unavailable.

Asmod4n• 4 months ago

Bloomberg has a clang implementation of reflection: https://github.com/bloomberg/clang-p2996

It has been on compiler explorer for a while

This has been used to add reflection to simdjson

VerifiedReports3• 4 months ago

As long as programmers still have to deal with header files, all of this is lipstick on a pig.

jjmarr9• 4 months ago

You don't on new projects. CMake + ninja has support for modules on gcc, clang, and MSVC.

This should be your default stack on any small-to-medium sized C++ project.

Bazel, the default pick for very large codebases, also has support for C++20 modules.

VerifiedReports3• 4 months ago

Thanks. It's been a long time since I started a C++ project, and I've never set up any build chain in Visual Studio or Xcode other than the default.

sgt3• 4 months ago

How about using Zig to build C++ projects?

duped5• 4 months ago

I have yet to see modules in the wild. What I have seen extensively are header-only projects.

72deluxe6• 4 months ago

I don't understand this at all. There are modules.

But headers are perfectly fine to deal with and have been for decades and decades! Next you'll be arguing that contents pages in all books should be removed.

VerifiedReports3• 4 months ago

What an absurd attitude. The gymnastics to avoid circular inclusions alone are something nobody should be giving a thought to in the 2000s.

"But headers are perfectly fine to deal with and have been for decades and decades!"

I would have thought this was a joke... but your follow-up indicates otherwise.

So what are you going to float next? "So what if people broke their arms hand-cranking their cars to start them! People did it for years, so we shouldn't move to electric starters! Or automatic chokes!"

"And these electric ice boxes are for the birds! Speaking of which: People flying through the air in machines? POPPYCOCK!"

pjmlp12• 4 months ago

I use modules in all my private projects since the last two years.

AyanamiKaine2• 4 months ago

I am actually excited for post and pre conditions. I think they are an underused feature in most languages.

augustk• 4 months ago

Postconditions are in conflict with programmers' love of early returns.

HelloNurse• 4 months ago

Formally, it doesn't appear to be so (tests can be added to each early return); in practice, encouraging the reorganization of messy early returns would be zero cost developer reeducation.

jcalvinowens4• 4 months ago

The "erroneous behavior" redefinition for reads of uninitialized variables is really interesting: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...

It does have a runtime cost. There's an attribute to force undefined behavior on read again and avoid the cost:

    int x [[indeterminate]];
    std::cin >> x;

augusto-moura• 4 months ago

Hm, I wonder if this will be a compiler flag too, probably yes, since some projects would prefer to init all variables by hand anyway.

WalterBright13• 4 months ago

D initializes all variables. If you don't provide an initializer, the compiler inserts the default initializer for it.

But if you really, really want to leave it uninitialized, write:

    int x = void;

where you're not writing that by accident.

Negitivefrags• 4 months ago

That is a way better syntax. I wonder why C++ didn't adopt it.

tialaramex14• 4 months ago

If you don't provide an initializer, the compiler inserts the default initializer for it.

This requires that there is a default. Several modern languages (such as Go) insist on this, it means now your types don't even model reality in this very fundamental way. Who is a person's default spouse? Even where you can imagine a default it's sometimes undesirable to have one, for example we already live in a society where somebody decided default gender is male - and it might look too much like real data, default birthday being 1 January also matches hundreds of thousands of Americans...

The most likely place you go after "Everything has a default" is the billion dollar mistake because you're inclined to just incorporate "or it's default invalid" into the type definition to get your default, and when you do that everywhere needs to have "check it's valid" code added, even if we already just checked that a moment ago.

ozgrakkurt9• 4 months ago

I envy the person that will walk into a c++ codebase and see "[[indeterminate]]" on some place. And then they will need to absolutely waste their time searching and reading what "[[indeterminate]]" means. Or over time they will just learn to ignore this crap and mentally filter it out when looking at code.

Just like when I was learning rust and trying to read some http code but it was impossible because each function had 5 generics and 2 traits.

jandrewrogers11• 4 months ago

What is non-obvious about “[[indeterminate]]”? That terminology has been used throughout the standards in exactly this context for ages. This just makes it explicit instead of implicit so that the compiler can know your intent.

amluto2• 4 months ago

On a quick read of the paper, I see two surprising things:

1. If there’s no initializer and various conditions are met, then “the bytes have erroneous values, where each value is determined by the implementation independently of the state of the program.

What does “independently” mean? Are we talking about all zeros? Is the implementation not permitted to use whatever arbitrary value was in memory? Why not?

2. What’s up with [[indeterminate]]? I would expect “indeterminate” to mean that the variable has a value that happens to be arbitrary (and may contain sensitive data, etc), not that it turns back into actual UB.

Dylan168072• 4 months ago

What does “independently” mean?

It can pick whatever value it wants and doesn't have to care what the program is doing.

Also the value has to stay the same until it's 'replaced'.

Are we talking about all zeros?

It might be, but probably won't be. What makes you bring up all zeroes?

Is the implementation not permitted to use whatever arbitrary value was in memory? Why not?

(Edit: probably wrong, also affects other things I said) It can. What suggests it wouldn't be able to?

2. What’s up with [[indeterminate]]? I would expect “indeterminate” to mean that the variable has a value that happens to be arbitrary (and may contain sensitive data, etc), not that it turns back into actual UB.

"has a value that happens to be arbitary" would be the default without [[indeterminate]]. Well, it can also error out if the compiler wants to do that.

aw162110716• 4 months ago

What does “independently” mean?

It means what it says on the tin. Whatever value ends up being used must not depend on the state of the program.

Are we talking about all zeros?

All zeros is an option, but the intent is to allow the implementation to pick other values as it sees fit:

Note that we do not want to mandate that the specific value actually be zero (like P2723R1 does), since we consider it valuable to allow implementations to use different “poison” values in different build modes. Different choices are conceivable here. A fixed value is more predictable, but also prevents useful debugging hints, and poses a greater risk of being deliberately relied upon by programmers.
Is the implementation not permitted to use whatever arbitrary value was in memory?

No, because the value in such a case can depend on the state of the program.

Why not?

Doing so would defeat the purpose of the change, which is to turn nasal-demons-on-mistake into something with less dire consequences:

In other words, it is still an "wrong" to read an uninitialized value, but if you do read it and the implementation does not otherwise stop you, you get some specific value. In general, implementations must exhibit the defined behaviour, at least up until a diagnostic is issued (if ever). There is no risk of running into the consequences associated with undefined behaviour (e.g. executing instructions not reflected in the source code, time-travel optimisations) when executing erroneous behaviour.
What’s up with [[indeterminate]]?

The idea is to provide a way to opt into the old full-UB behavior if you can't afford the cost of the new behavior.

I would expect “indeterminate” to mean that the variable has a value that happens to be arbitrary (and may contain sensitive data, etc), not that it turns back into actual UB.

I believe the spelling matches how the term was used in previous standards. For example, from the C++23 standard [0] (italics in original):

When storage for an object with automatic or dynamic storage duration is obtained, the object has an indeterminate value, and if no initialization is performed for the object, that object retains an indeterminate value until that value is replaced.

[0] https://open-std.org/JTC1/SC22/WG21/docs/papers/2023/n4950.p...

ill_ion• 4 months ago

Contracts feel like the right direction but the wrong execution timeline. The Ada/SPARK model shows how powerful contracts become when they feed into static verification — but that took decades of iteration on a language with far cleaner semantics. Bolting that onto C++ where UB is load-bearing infrastructure is a different beast entirely. The real risk isn't complexity for complexity's sake — it's that a "minimum viable" contracts spec gets locked in, and then the things that would actually make it useful for proof assistants become impossible to retrofit because they'd break the v1 semantics. Bjarne's concern about "incomplete" is more worrying to me than "bloated."

sgt3• 4 months ago

Nice try, clanker slop

chrisaycock• 4 months ago

std::execution is very interesting, but will be difficult to get started with, as cautioned by Sutter. This HPC Wire article demonstrates how to use standard C++ to benefit from asynchronously parallel computation on both CUDA and MPI:

https://www.hpcwire.com/2022/12/05/new-c-sender-library-enab...

Overlapping communication and computation has been a common technique for decades in high-performance computing to "hide latency", which leads to better scaling. Now standard C++ can be used to express parallel algorithms without tying to a specific scheduler.

pjmlp12• 4 months ago

NVidia is the main sponsor of this kind of work, and a few key figures are nowadays on their payroll.

FpUser2• 4 months ago

I am curious what is their strategy to get language to the stage where the US government will make it cosher for new projects

jandrewrogers11• 4 months ago

No such strategy is necessary. That discourse was about not using C++ for applications where Java would work just as well.

The US government still uses C++ widely for new projects. For some types of applications it is actually the language of choice and will remain so for the foreseeable future.

FpUser2• 4 months ago

"For some types of applications it is actually the language of choice..."

Can you give an example please? And how does it correspond to government ONCD report and other government docs "recommending" "safe" languages like: Rust (noted for its ability to prevent memory-unsafe code), Go, Java, Swift, C#, Ruby, Ada

Among other things I design and implement high performance C++ backends. for some I got SOCS2 Type II certification but I am curious about future. Do not give a flying fuck about what the criteria for military projects as I would not ever touch one even if given a chance.

Tenobrus• 4 months ago

"Japanese soldier who kept fighting 29 years after World War 2"

cedws2• 4 months ago

I watched a talk from Bjarne Stroustrup at CppCon about safety and it was pretty second hand embarrassing watching him try to pretend C++ has always been safe and safety mattered all along to them before Rust came along.

einpoklum7• 4 months ago

Well, there has been a long campaign against manual memory management - well before Rust was a thing. And along with that, a push for less use of raw pointers, less index loops etc. - all measures which, when adopted, reduce memory safety hazards significantly. Following the Core Guideliness also helps, as does using span's. Compiler warnings has improved, as has static analysis, also in a long process preceding Rust.

Of course, this is not completely guaranteed safety - but safety has certainly mattered.

einpoklum7• 4 months ago

If you ask me (and why wouldn't you? :-)...) I really wish the C++ WG would do several things:

1. Standardize a `restrict` keyword and semantics for it (tricky for struct/class fields, but should be done).

2. Uniform Function Call Syntax! That is, make the syntax `obj.f(arg)` mean simply `f(obj, arg)` . That would make my life much easier, both as a user of classes and as their author. In my library authoring work particularly. And while we're at it, let us us a class' name as a namespace for static methods, so that Obj::f the static method is simply the method f in namespace Obj.

3. Get compiler makers to have an ABI break, so that we can do things like passing wrapped values in registers rather than going through memory. See: https://stackoverflow.com/q/58339165/1593077

4. Get rid of the current allocators in the standard library, which are type-specific (ridiculous) and return pointers rather than regions of memory. And speaking of memory regions (i.e. with address and size but no element type) - that should be standardized too.

tourist2d• 4 months ago

1. This seems like it's be far too tricky and make C++ even more footgunny, especially with references, move constructors, etc etc.

2. Name lookup and overload resolution is already so complex though! This will likely never be added because it's so core c++ and would break so much. imo, it also blurs the line between what's your interface vs what I've defined.

3. This is every junior c++ engineers suggestion. Having ABI breaks would probably kill c++, even though it would improve the language long term.

4. Again, you make solid points and I think a lot of the committee would agree with you. However, the committee's job is to adapt C++ in a backwards supporting way, not to disrupt it's users and API each new release.

There are definitely things to fix in c++ and every graduate engineer I've managed has had the same opinions of patching the standard, without considering the full picture.

einpoklum7• 4 months ago

Re (1.): Not-having-footguns is not a basic design principle of C++. But principles which it is supposed to adhere to include:

* Don't pay for what you don't use;

* Not leaving for another language between C++ and assembly (or to phrase it differently: "when you use an abstraction mechanism appropriately, you get at least as good performance as if you had hand-coded using lower-level constructs")

and the lack of `restrict` breaks both of these, significantly. Because compilers are forced to implement even simple functions with repeated re-reading of data - due to the possibility of aliasing - which the software developer knows is entirely unnecessary, and would have avoided had he been writing the same function in, say, C (and of course compiler IR or assembly)

Re (2): It's not really "core C++": It would not make any existing program non-well-formed, nor change its semantics, at all. But it's true that this would have an impact on how we design classes - and that's the exact intent. And it does far more than "blur the line between what's your interface vs what I've defined" - it deletes most of this line, ,and that is exactly the point. The line we should have is the line of acccess restriction: Does a method have access to the class' private data, or doesn't it. If it doesn't, then, there are simply functions which take an oject of the class; and it doesn't matter if the class author defined them or if someone else defined them.

Re (3.): I didn't say lack of backwards compatibility, just that going forwards, ABIs would allow some things which are currently prevented [1]. I am not an ABI expert in the least, but IIUC, use of new ABI can be marked, so that nothing gets mixed up.

I would also claim that ABI stability should cede to the design principles I mentioned above.

[1] https://cor3ntin.github.io/posts/abi/

pjmlp12• 4 months ago

The C++ WG is like any other open source project, even when it doesn't look like it.

Someone has to bring a written spec to WG21 meetings and push it through.

And like in every open source project that doesn't go the way we like, the work is only done by those that show up.

einpoklum7• 4 months ago

The C++ WG is like any other open source project, even when it doesn't look like it.

In many ways, it isn't.

Someone has to bring a written spec to WG21 meetings and push it through.

That is one way it is not like (most) other FOSS projects. In a typical FOSS project, there are bug reports and feature/change requests that people file. They don't have to write a full article merely for their idea to be given the time of day. Certainly not have to appear physically at meetings held elsewhere in the world. Of course, the question of the extent to which ideas and requests from the public are considered seriously and fairly is a spectrum - some FOSS projects give them more attention and consider them seriously, others do not. vis-a-vis WG21 the "public" is, to some extent: Compiler author teams, standard library author teams, national bodies, and large corporations using C++. This is perhaps not entirely avoidable, since there are millions of C++ users, but still.

Anyway, what I described isn't just some personal ideas of mine, it is for the most part ideas which have been put forward before the committee, either directly in submitted papers or indirectly via public discussion in fora the committee is aware of.

bluGill12• 4 months ago

2 sounds good, but it will break a lot of existing code what suddenly does something different. At least so far every version of the rules someone has come up with has had a real world example of code that would be seriously broken if it was in place.

germandiago7• 4 months ago

I think you cannot get an idea of in hiw many ways 2. can break...

gpderetta5• 4 months ago

re 3, clang has [[trivial_abi]] (and I believe GCC is also implementing it. But it won't be applied to standard types by default, because of course is ABI breaking. You'll have to derive your own.

rr808• 4 months ago

I switched from C++ to Java/Python 20 years ago. I never really fit in, I just dont understand when people talk about the complicated frameworks to avoid multithreading/mutexes etc when basic C++ multi threading is much simpler than rxjava or async/await or whatever is flavor of the month.

But C++ projects are usually really boring. I want to go back but glad I left. Has anyone found a place where C++ style programming is in fashion but isn't quite C++? I hope that makes sense.

xonre• 4 months ago

That place is C++/Lua, with most of the code in Lua. Concurrency model is thread-per-lua-state. Interthread comms is message passing implemented via textbook c++11 atomic and condition variables. Lua is just a small C library so the style remains very friendly to those who like C with classes.

ozgrakkurt9• 4 months ago

It looks like they didn't even add _BitInt types yet. Adding concepts but not adding _BitInt types sounds insane considering how simple _BitInt types are as a programmer (not sure about implementation but it already works in clang).

jandrewrogers11• 4 months ago

_BitInt types probably aren’t a priority because they are more or less trivial to implement yourself in C++.

Also, some of the implementation details and semantics do matter in an application dependent way, which makes it a bit of an opinionated feature. I would guess there is a lot of arguing over the set of tradeoffs suitable for a standard, since C++ tends to avoid opinionated designs if it can.

pjmlp12• 4 months ago

Just like restrict never made it.

Someone has to write a proposal, bring it to the various meetings, and getting it to win the features selection election from all parties.

Also WG21 tends to disregard C features that can already be implemented within C++'s type system.

BiraIgnacio• 4 months ago

If C++29 was exclusively about quality-of-life improvements, improving what exists, I'd bet the community wouldn't mind too much.

bluGill12• 4 months ago

That depends on what else comes. There are a lot of ideas, some of which will get the community excited.

m-schuetz4• 4 months ago

All I want from C++29 is a single-line random() function.

vr46• 4 months ago

Hosting the meeting in Croydon and not letting people leave until the thing is signed-off is definitely a cunning strategy. Never want to work down there again, ever.

Milner08• 4 months ago

Quite unrelated to the main topic, but shouldn't it be Croydon, London? I have never heard anyone called it London Croydon before. Generally addresses/places go from most specific to least and given Croydon is an area of London it should go first.

sidkshatriya5• 4 months ago

Yes, I noticed that too -- why "London Croydon" rather than "Croydon, London" ?

Date in Europe: 30/03/2026

Date in China: 2026/03/30

Then you have Little Endian and you have Big Endian.

TL;DR: Some humans like to talk about the specific and then the general and others vice versa.

But here is really why I think the author referred to it as "London, Croydon"

"London, Croydon" communicates "Hey we had this C++ standards meeting in London, one of the coolest cities in the world. (Be jealous!). We were helping add more complexity to the most complex language in the world in the lovely environment of London, England. Croydon is a piece of irrelevant detail... meeting was in London, remember that !

"Croydon, London" communicates "Hey we had this C++ standards meeting in gritty Croydon... it was in London so I guess it was OK ?? Sorry our budgets could not put us up in Westminister, London"

[End of Joke]

tialaramex14• 4 months ago

Generously - specifying Croydon does help travellers figure out where they need to be more specifically than just London. I'd like to hope if they met in New York City it'd say e.g. "New York - Riverdale" or something rather than leaving you to guess where in the city exactly.

Most things "in" London aren't in the centre unless they're tourist destinations or they're extremely old. The most surprising thing I ran into right in the centre was the International Maritime Organisation's headquarters, which is right on the Thames because historically that makes sense in a way that arguably it already didn't when that was built, and certainly not today.

nutjob2• 4 months ago

Like London Gatwick Airport?

Addresses are one thing, but the inverse has its own logic. In terms of (mental) planning you want to know that you need to go to the UK then London then Croydon, otherwise there's an element of "where's that?" as you read left to right.

superxpro122• 4 months ago

C++ is so tantalizingly close to being an amazing embedded c++ language if they could JUST support first-class polymorphism.

Embedded is such a perfect fit for interface-based programming, but because it cant determine call resolution outside of a single source file, EVERYTHING gets vtable'd, which ruins downstream optimizations.

There's some ugly workarounds.... CRTP, c-style (common header + different source files. To the person who says "use templates!".... no. I dont like templates. They are verbose, complex, and every time i try to use them they I end up foot-gunning myself. Maybe its a skill issue, but if you designed something that most people cant figure out, I'd argue the design is wrong.

C++ is SOOO close to doing compile-time polymorphism. If just needs a way to determine type across source files, which LTO sorta-kinda-but-not-really does.

I've seen some examples of C++ contracts replacing CRTP, but it used templates, which again, not a fan of.

QuiEgo• 4 months ago

Rust’s trait system and the embedded HAL say “hi there.”

gpderetta5• 4 months ago

use templates.

majoe• 4 months ago

I've seen some examples of C++ contracts replacing CRTP, but it used templates, which again, not a fan of.

I think you meant concepts.

C++ Concepts are the right answer in my opinion, if you want compile time polymorphism against an interface.

I don't think, there is a way around templates, they are C++'s way of compile-time polymorphism. Other languages, which allow for compile-time polymorphism, have similar mechanisms with similar constraints. I get where you come from, when you say that you're not a fan of templates, though. At least concepts help with clearer error messages for templates.

One advantage, that concepts have over CRTP is, that only consumers of your interface, not implementers, need to know about your concept.

DonHopkins• 4 months ago

Dammit, it's been 28 years and they still haven't implemented my favorite C++ extension proposal, and its birthday is coming in a couple days -- it would be so much better now with all the emojis in unicode:

Generalizing Overloading for C++2000

https://www.stroustrup.com/whitespace98.pdf

semiinfinitely• 4 months ago

Just in time for language deprecation

hulitu• 4 months ago

C++26 is done

Now do C++27. Why do we need every year a standard ? CADT ?

relation_al• 4 months ago

As more of a C# and Java guy, I'm curious to understand something - what sort of apps do folks here build? I am very interested to hear what problems get solved with these languages today. I know there must be many use-cases, but I don't hear about them too much.

C++26 is done: ISO C++ standards meeting Trip Report

Related Stories