- 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.
- 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."
by chrisaycock
0 subcomment
- 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.
by jcalvinowens
0 subcomment
- 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;
- > 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?
by LatencyKills
0 subcomment
- 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.
by mohamedkoubaa
3 subcomments
- Biggest open question is whether the small changes to the module system in this standard will actually lead to more widespread adoption
by AyanamiKaine
0 subcomment
- I am actually excited for post and pre conditions. I think they are an underused feature in most languages.
- 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.
by levodelellis
0 subcomment
- 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
- I don't care until they stop pretending Unicode doesn't exist.
by VerifiedReports
1 subcomments
- As long as programmers still have to deal with header files, all of this is lipstick on a pig.
- Sadly, transparent hash strings for unordered_map are out.
by rustyhancock
1 subcomments
- I look forwards to getting to make use of this in 2040!
Proper reflection is exciting.
by the__alchemist
1 subcomments
- Seeing that pic at the top of the article, and reflecting on my own experiences with rust: It is wild just how male-centric systems programming languages are. I'm from a career backround that's traditionally male-dominated (military aviation), but the balance is far more skewed among C, C++ and Rust developers.
Hacker News