When a language's creator and its owners strongly disagree [pdf]

Stroustrup's list of objections sounds quite sensible to me: https://www.stroustrup.com/Contracts_fundamental_flaws.pdf

I think this is putting too much weight on this event and Bjarne’s position on contracts.

Bjarne’s opposition to contracts might have tipped the scale but there is definitely growing weariness (and wariness) about large half-baked features that are left as exercises to the implementors (looking at you modules).

Ignoring that historical context when analysing this vote seems like a mistake.

This is a well-written and quite diplomatic summary by Herb Sutter. I'm not plugged in enough to be sure he's correct that Stroustrup's opposition was the main reason the C++26 vote failed where others have passed, but it sounds plausible.

It also lists 6 possible paths forward for C++26 with pros and cons. I think they are roughly:

A. Skip an official C++26 standard but roll these features into C++29.

B. Remove contracts from C++26 and pass it.

C. Say "please" and vote again.

D. Tweak contracts regarding virtual functions and vote again.

E. Pass C++26 as many different countries' national standards rather than an international standard.

F. Do E and also consider leaving ISO and moving to ANSI/INCITS instead.

I haven't really paid attention to C++ in a while (last neat feature I saw was concepts). Usually I kind of enjoy the weird, expressive code golf you can write with the new features. For example I tried out using concepts to ensure Matrix dimensions were compatible with the desired operation. Not really that useful, but was a neat thought experiment.

But these proposed contracts... I just don't really see much benefit it offers over just explicitly writing your own assertions.

I suppose you can see the requirements in the declarations, but I would wager that fancy modern C++ declarations quickly become so long and verbose that you'd get quickly fatigued from reading them. Perhaps in the LLM era they are more useful?

As someone who spent a few weeks trying to get into C++ (pre-LLM, so maybe it's better now?) and kind of just gave up out of confusion, I really found it challenging to deal with the multiple different ways to do something. I mean, which pointer should I use? How should I iterate? I'm sure there's an answer to this, but I just found it easier to go back to python and hit up rust when I needed it.

It seems like part of the concern is that the feature needs to be shipped right the first time because it'll live forever. Perhaps allowing features to be deprecated and then removed could help?

But idk, I haven't written anything that lasted 36 years, so maybe the current approach is for the best!

36 years of sustained agreement is not good; it means nobody is saying no to anything, and you have a giant, dirty snowball rolling down a mountain.

Just stopped by to say Sutter is not only right to be reiterating Bjarne's position here, he is also the author of IMO the most impactful paper regarding the progress of hardware performance and the shift to concurrent execution: https://www.cs.utexas.edu/~lin/cs380p/Free_Lunch.pdf

Nice that perl got a mention, but it is not especially nuanced. Raku is not a fork of perl, it's a new language. That is why it got a new name. It was intended to be backward compatible, just didn't work out that way. However, Raku's FFI lets Raku code call into perl, and vice versa.

I'm sure I'm not the only one but I feel like C++ is over/done. I work in a C++ code base and have been doing C++ for > 20 years and to me at least, the writing is on the wall.

1. C++ is unsafe. Bjarne keeps giving talks that effectively say "use it perfectly and don't make any mistakes and it's safe". That's not useful anymore. In a world where LLMs can find every mistake to exploit it, all the C++ projects are struggling to keep up and keeping them in C++ is basically guaranteeing there will be more exploits in the future. Yes, not every bug gets solved by switching to a safer language but reducing the attack surface in the new reality is no longer something that can be put off.

2. LLMs can re-write. The previous arguments used to be "there are C++ legacy code bases so C++ will never die". That was a valid argument before an LLM would just rewrite it all. I get people will say they aren't perfect, neither are humans though. Further they get better all the time, and we see their progress. People pointing an LLM at some project and it magically making it work on some other platform etc... It's clear it's happening.

Time to remove c++ from your resumes old men!

    auto fib = [](this auto self, int n) -> int { return n < 2 ? n : self(n-1) + self(n-2); };
    auto v =  std::views::iota(0, 20) | std::views::transform(fib) | std::ranges::to<std::vector>();
    for (auto&& [i, x] : v | std::views::enumerate) std::println("{} -> {}", i, x);
    auto add = []<typename... Ts>(Ts&&... ts) { return (... + ts); };
    static_assert(add(1, 2, 3) == 6 && requires { std::format("{}", 'x'); });

I'm amazed. Someone somewhere conceived of a feature, and it wasn't put into C++!

> Fact 1: WG21 has strong consensus for contracts

It very obviously does not. Stating what you want to be true as "facts" does not make it so but rather discredits the one making the assertion.

Not only did Kernighan and Ritchie not update the C book for a standard newer than C89, Kernighan underscored that by updating the The Awk Book in 2023 (with Aho and Weinberger: the other two letters in Awk). As if to say C is so far gone that even Awk is more worth writing about.

Before reading it i was sure this was going to be about how the PHP creator warned everyone hes language was for blogging, then we had an apocalipse

[flagged]

“Owners”? No one owns a language. People will do what they find pragmatic, practical and necessary. A committee who thinks they own a programming language has become pretentious and misunderstands their relationship with developers.

[flagged]