C++26 is done: ISO C++ standards meeting Trip Report • Hacker News Board

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

#261

Post by maccard » Mon, Mar 30, 2026, 1:03 PM UTC

superxpro12 wrote: post #250

zarzavat wrote: post #7

Earlier quoted context omitted.

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.

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…

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

I agree, and I also think it’s never happening. It requires agreeing on so many things that are subjective and likely change behaviour. C++ couldn’t even manage to get module names to be required to match the file name. That was for a new feature that would have allowed us to figure out esports without actually opening the file…

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

#262

Post by QuiEgo » Mon, Mar 30, 2026, 1:06 PM UTC

superxpro12 wrote: post #255

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.…

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

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

#263

Post by yolina » Mon, Mar 30, 2026, 1:07 PM UTC

mcdeltat wrote: post #151

Guvante wrote: post #133

Earlier quoted context omitted.

Why should C++ stop improving? Other languages don't need C++ to die to beat it.

Half-serious reason: because with each C++ version, we seem to get less and less what we want and more and more inefficiency. In terms of language design and compiler implementation. Are we even at feature-completeness for C++20 on major compilers yet? (In an actually usable bug-free way, not an on-paper "completion".)

gcc seems to have full C++20, almost everything in 23 and and implemented reflection for 26 which is probably the only thing anyone cares about in 26.

https://en.cppreference.com/w/cpp/compiler_support.html

Funny how gcc seems to be the top dog now, what happened to clang? Thought their codebase was supposed to be easier and more pleasant to work with? Or maybe just more hardcore compiler devs work on gcc?

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

#264

Post by sidkshatriya » Mon, Mar 30, 2026, 1:08 PM UTC

mort96 wrote: post #216

WalterBright wrote: post #153

Earlier quoted context omitted.

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

How do you know nobody wanted it?

> How do you know nobody wanted it?

Some imperfect data points on how to judge if a language feature is wanted (or not):

- Discussion on forums about how to use the feature

- Programs in the wild using the feature

- Bug reports showing people trying to use the feature and occasionally producing funny interactions with other parts of the language

- People wanting to do more complex things on the initially built feature by filing features requests. (Showing that there is uptake on the feature and people want to do more fancy advanced things)

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

#265

Post by yolina » Mon, Mar 30, 2026, 1:10 PM UTC

kajaktum wrote: post #121

addaon wrote: post #17

Earlier quoted context omitted.

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 tha…

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.

Some other language need to step up and rewrite/replace LLVM then, because no language that relies on a ~30 million loc backend written in C++ can ever hope to replace it.

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

#266

Post by bluGill » Mon, Mar 30, 2026, 1:10 PM UTC

WalterBright wrote: post #154

selfmodruntime wrote: post #108

Earlier quoted context omitted.

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.

In D, we are implementing editions so features that didn't prove effective can be removed.

I don't know what you mean by effective - I can come up with several different/conflicting definitions in this context.

I think what you meant to say is popular. If a feature is popular it doesn't matter how bad it turns out in hindsight: you can't remove it without breaking too much code (you can slowly deprecate it over time, I'm not sure how you handle deprecation in D, so perhaps that is what editions give you). However if a great feature turns out not to be used you can remove it (presumably to replace it with a better version that you hope people will use this time, possibly reusing the old syntax in a slightly incompatible way)

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

#267

Post by sidkshatriya » Mon, Mar 30, 2026, 1:13 PM UTC

locknitpicker wrote: post #223

WalterBright wrote: post #153

Earlier quoted context omitted.

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

> 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?

> I understand you want to self-promote

Not a very fair assumption. However, even if your not so friendly point was even true, I'd like people who have invented popular languages to "self-promote" more (here dlang). It is great to get comments on HN from people who have actually achieved something nice !

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

#268

Post by bluGill » Mon, Mar 30, 2026, 1:13 PM UTC

btilly wrote: post #143

gmueckl wrote: post #102

Earlier quoted context omitted.

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 be…

That sounds like the worst kind of misfeature. It sounds like it should solve your problem. At first it seems to work. Then you keep on finding the footguns after it is too late to change the design.

Contracts are designed as a minimum thing that can work. The different groups who want different - conflicting - things out of contracts now have a common place and syntax examples to start adding what they want without coming up with something that either breaks someone else, or worse each group doing things in a non-uniform way thus causing foot guns.

Contracts as they are today won't solve every problem. However they can expand over time to solve more problems. (or at least that is the hope, time will tell - there is already a lot of discussion on what the others should be)

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

#269

Post by sidkshatriya » Mon, Mar 30, 2026, 1:18 PM UTC

ChrisGreenHeur wrote: post #164

WalterBright wrote: post #153

Earlier quoted context omitted.

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

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

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

This is actually a good point. Yes, LLMs have saturated the conversation everywhere but contracts help clarify the pre-post conditions of methods well. I don't know how good the implementation in C++ will be but LLMs should be able to really exploit them well.

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

#270

Post by sidkshatriya » Mon, Mar 30, 2026, 1:22 PM UTC

jandrewrogers wrote: post #171

ozgrakkurt wrote: post #163

Earlier quoted context omitted.

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 t…

Many of the recent C++ standards have been focused on expanding and cleaning up its powerful compile-time and metaprogramming capabilities, which it initially inherited by accident decades ago. It is difficult to overstate just how important these features are for high-performance and high-reliability systems software. These features greatly expand the kinds of safety guarantees that are possible to automate and the…

One of the biggest knocks against Rust as a systems programming language is that it has weak compile-time and metaprogramming capabilities compared to Zig and C++

In the space of language design, everything "more powerful" is not necessary good. Sometimes less power is better because it leads to more optimisable code, less implementation complexity, less abstraction, better LSP support. TL;DR More flexibility and complexity is not always good.

Though I would also challenge the fact that Rust's metaprogramming model is "not powerful enough". I think it can be.