Here's an example that uses compile time type assertions (static_assert, C++ can already do this), runtime errors (CHECK, standard Google/abseil practice for explicitly handling invalid states and invariants), test/dev checks (more of a defensive programming inline test than a pre or post condition), and wrapper/error handling types to do the same kinds of things as you might think to use contracts for.

  template <typename T>
  absl::StatusOr<double> Percentile(std::span<const T> sorted_values, double p) {
    static_assert(std::is_arithmetic_v<T>, "T must be numeric");
    CHECK(p >= 0.0 && p <= 100.0) << "p out of range: " << p;
    DCHECK(std::ranges::is_sorted(sorted_values)) << "input not sorted";

    if (sorted_values.empty()) {
      return absl::InvalidArgumentError("empty input");
    }

    const std::size_t last = sorted_values.size() - 1;
    const double rank = p / 100.0 * last;
    const auto lo = static_cast<std::size_t>(rank);
    const std::size_t hi = std::min(lo + 1, last);
    const double result = std::lerp<double>(sorted_values[lo], sorted_values[hi],
                                          rank - lo);

    DCHECK(result >= sorted_values.front() && result <= sorted_values.back());
    return result;
  }

Before I was exposed to this style of C++ and learned to write it this way, it basically felt like a different language. You often hear people say that the C++ standards committee and language designers seem to have different priorities and developer culture vs most big tech companies/finance and I think it's because even if they're aware of the features and tools that come out of Google (et al) [1], they don't use them in their current day to day jobs and want that functionality in the core C++ toolchain.

IMO the problem is that a lot of what they want to add to the language is already "solved" by third party tooling, but because for whatever reason they don't use those existing solutions as part of their everyday work, they sometimes come up with language features that overcomplicate or solve the wrong thing, in a way that you would intuitively understand if you were already regularly using 3P tools to solve them.

I could also be the one misinterpreting things here so apologies if this is obvious or not what the original commenter meant by "high reliability".

[0] https://en.wikipedia.org/wiki/High_Integrity_C%2B%2B

[1] https://abseil.io/about/ is one of many third party ways to make C++ less insane

One of the best features to be added to C++ in many years.

C++ contracts are an attempt to bring C asserts into the C++ age. The weakness of C++ contracts is that they are mostly syntactic sugar over C asserts. If you really care about this type of thing, you probably already have a custom C++ assertion framework that is at least as capable if not more.

The promise of C++ contracts is that they can aid formal verification, which would be great. As delivered, it can’t do much more than was already possible, which will inhibit adoption.

Phrased differently, contracts are to concepts what assert is to static_assert.

Contracts notionally offer the ability to lift some runtime assertions to compile-time. That is how it was sold. Except they don’t in practice.

Meanwhile, concepts + constexpr if used artfully deliver that in practice, including for many cases that contracts were supposed to solve.

I push all verification to compile-time to the extent possible.

The only extreme and tone deaf thing I see in this story is how contracts proponents were faced with multiple papers demonstrating quite clearly and extensively how they were broken in specification and in form, but still tried to ignore all the criticism and force them through a consensus process in spite of being clearly opposed.

How does this make any sense? What was the plan here? To blackmail the C++ community to accept a broken feature under threat of the proposal not passing?

Make it make sense?

What I want to see is the people who tried to force contacts upon the process in spite of all opposition to come forth and explain their rationale. It was highly absurd and even unthinkable to force a broken feature down C++'s throats with bureaucratic chicanery, and then complain that the same bureaucracy has mechanisms to stop it's abuse. I for one would like to hear an explanation.

Like most people in this thread, you should really read up on contracts before commenting. The contracts proposal is for runtime assertions, and their problem is that they are poorly specified and fundamentally broken. Their proponents haven't been addressing any of their concerns and tried to push a half baked version of them down everyone's throats, which was why they failed to pass.

Spoiler alert: The option described as "the sort of leadership failing that I pray we can avoid" is what ended up happening.

I mean, I mainly say this to joke because it's probably unfixable at this point, but whenever I mess with it, I'm struck by how hard/opaque C++ makes this problem compared to most other languages.

C++ is unique in that it defines a spec for STL but not implementation. The result is something that is both overspecified and underspecified.

Including batteries is fine. Including a spec for what the batteries should look like is such a profoundly bad idea that no other major language does it.

I think the author is trying to get at like, the actual discussion happens earlier / on the WG21 level, and the ISO vote is treated more of a rubberstamp. And that has changed in this instance.

That's my opinion as well. It's a smear campaign lashing back at people who dared to point out flaws.

The author even explicitly states that "errors in the process" are another potential reason for the NB's to vote against a proposal, so why focus solely on the "no new information" argument?

Also, keep in mind that the WG21 operates primarily by consensus[0], which is explicitly not a majority vote. The final vote for Contracts was 114 in favor, 12 opposed, 3 abstaining, which some consider "an unusual level of opposition" with "tangible debate"[1].

I assume the default is for people to trust that the domain experts in the various subcommittees did their work properly, so an in-favor vote would be more a "I trust the subcommittee / I don't care about this feature" than an explicit "I approve of this feature", with an opposing vote basically being "the subcommittee is making a grave error, this is obviously going to blow up in our faces".

Extend this to the NB level, and the disapproval is basically a vote of "Wait, do we really want to standardize something which is still facing very serious opposition?"

[0]: https://isocpp.org/std/standing-documents/sd-4-wg21-practice...

[1]: https://componentsprogramming.com/cpp26-croydon-wg21-meeting...

Certainly safer, but not memory safe. Operations as simple as multiplying signed integers or popping an empty vec can be undefined behavior which is not memory safe.

Stroustrup is 75 years old. This is not only hard to believe because of his age, but also because it requires that people who oppose his views somehow have distinct sleeping patterns from ones who agree with his views. Weird, man.

There were no "dirty tricks". The C++ standards committee works by a vaguely defined "consensus", which requires more than "the majority rules". Contracts got added to the C++26 draft. Then there was consensus that Contracts needed to be fixed, but they could never get consensus on any particular fix. So they cruised along relatively unchanged.

In the end, the only way to NOT accept a marginal Contracts feature was to vote down the full language spec. Now they'll regroup and decide how to proceed.

I have personally seen several hundred use cases for SIMD that are just fine with portable intrinsics, and NOT always "platform-specific data structures and algorithms". Sure, that does happen, but not fundamentally, nor even often.

To be clear, I agree the compiler isn't solving the data layout problem for us, but portable intrinsics are indeed useful.

gemma.cpp uses them, and last I checked, has much faster long-context prefill and decode vs. llama.cpp. They hand-roll the intrinsics and presumably it is harder to land optimizations repeated across 7+ implementations/instruction sets.

ISPC doesn't a pretty good job of it: https://ispc.github.io/

std::simd is unfortunately very limited.

cppreference is often a bit too technical for its own good :)

But I think there's a broader issue which is that if it took me multiple searches to find a good-enough visual "pitch" for what contracts look like in practice, its champions have not yet won hearts and minds - which brings us to the situation at hand.

I wouldn't choose Go because GC is a non-starter.

I wouldn't choose C because it's nice to have some form of generics or metaprogramming, even if templates are not exactly fantastic.

I wouldn't choose Zig because the language isn't stable, and the lead developer has hinted that they'll drop LLVM down the line, and I don't want to beta test their compiler backend.

I think it was a fair question. As someone who doesn’t follow C++ I really don’t know what else was in the proposal. It’s nice to hear there is memory safety stuff.

Could you expand on what specific safety features C++ has that Rust doesn't?

A much more accurate snapshot would be Github - they recently published the top langauges for the year (so far, up til Sept 2026) by distinct monthly contributors and C++ comes in at 9 out of the top 10, and Rust doesn't even place in the top 10 yet, so yes it is highly relevant and prevalent, but not because TIOBE said so.

But, TypeScript, Python and Rust are the fastest growing languages, in that order, so also you cannot discount Rust.

https://github.blog/news-insights/octoverse/octoverse-commit...

But, of course, there is still a lot of new C++ code written, more than Rust. I believe C++ will become legacy, but it's not there yet and even once that happens it'll take at least decades to stop writing C++.

Personally, I think it is still relevant. Many people thought Kotlin could overtake Java, Java reinvented itself with new initiatives/features and was saved from becoming irrelevant.

Rust also has the LLM advantage which is where I think the "if it compiles it works" nature of Rust is easier for manual changes and maintenance when needed.

Even in their case. Rust depends on LLVM which is wriiten in C++. Go needs libc on some platforms.

Support for contracts is fairly broad and spans numerous organizations.