Does this contrast what anyone else has found, regarding usage in the wild?

You think Stroustrup's decision making is primarily decided by what's currently hype on HN?

Did people not read articles and books with em-dashes before LLMs? Why are we pretending nobody used them before? It's one of the first things people learn to typeset properly when learning LaTeX for the first time, not to mention so many books we grew up reading used them regularly.

I routinely use em dashes. They are easy to type on Mac and Linux. Only Windows makes it a hurdle.

Bjarne uses Microsoft Word (the style used in the document gives it away) and it auto-emdashes by default when you just type a normal -

> What does guaranteed enforcement mean?

I'm not sure I can express it better than the proposal to add the corresponding feature [0]:

> This extension addresses the Romanian National Body's (NB) concern by enabling the writing of an individual contract assertion that guarantees the program execution will not continue past the contract assertion if it is violated, regardless of the semantics of other contract assertions. This addition to the C++26 Contracts facility allows reliable use of enforced contract assertions in large codebases with mixed contract semantics and also in hardened libraries.

> Is it worth the trade-offs?

Apparently some people/NBs feel quite strongly that it is.

> There's a reason why most code turns assert off in production and only does it in debug builds.

There's also a reason some codebases define asserts that aren't turned off in production in addition to debug-only asserts. The proposal lists multiple under Section 3.1 Existing Practice.

> and so if the code is trusted to work, you wouldn't want to check that it's working correctly.

Right, but sometimes you might think the consequences of such blind trust being misplaced are worse than the performance hit.

Static detection of impossible-to-satisfy contract conditions would be interesting, but as you say the technology is probably not ready for the kind of widespread use that inclusion in C++ would entail.

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p39...

> There is no formal deprecation or EOL process

Yes there is or we'd have been talking about std::auto_ptr as well.

> New features rarely undermine or reinvent the older ones.

Many languages have mistakes they've later tried to sweep under the rug. JavaScript arrow functions trying to convince everyone that bind(this) wasn't ever a thing, for example.

C++, for whatever reason, is consistently the only language where people are determined to always dig up the skeletons and pretend they are at all still relevant. It's not unique in having skeletons. It's not unique in having language spec mistakes that can't realistically be changed, just ammended with a newer, better alternative.

But like the saying goes, there are only two kinds of languages: the ones people complain about and the ones nobody uses

...which is the same as nearly every other language? What language doesn't have that same collection of stuff?

Java: for, for-each, do-while with iterator, list.forEach(..), list.stream().forEach(..), etc...

Knowing the story behind a decision like that is worth a thousand spec clauses.

When the language got operator overloading there was the question of how to convert the arguments from the operator itself to its implementation. You wanted to write a+b, not &a+&b but most versions of operator+ were going to want const pointers for efficiency. One option was to make the & implicit, another was to introduce a type of argument that didn't need & but acted like a pointer. So references were born.

I ignore people who advise to use references when something can't be null. A null reference is UB just like a null pointer, it just shifts where the UB is, but the compiler is likely to produce the same code either way and the program is just as likely to crash. Instead, I use pointers to make it obvious that something is a pointer, and references when it should be invisible, just like with operator overloading.

Made me LOL

Explanation: shared_ptr is an implementation of "reference counting". All shared_ptrs to the same object collaborate to know how many of them exist (it's just a ++ on creation of one, -- on destruction of one) and when the last one is destroyed it also destroys the object that's pointed to.

weak_ptr is like shared_ptr but doesn't add to the count. When the last shared_ptr is destroyed it destroys the object even if there are still weak_ptrs. Any weak_ptrs pointing to that object become null. I won't dive into how that's actually implemented. Obviously it costs some CPU cycles to make that happen, so you don't see shared_ptr or weak_ptr a lot in code that's written with a performance mindset. Although you're still getting 90% of the performance benefit by writing C++ instead of JS even if it's "inefficient" C++.

I agree with GP's point and add, if this isn't something you need to do, then don't even think about it. C++ is like a toolbox with a bunch of tools. I don't study all the tools before building a table, I look up how to build a table, and then see if the tools are in my toolbox. Studying the triangle screwdriver would be a waste of time and only confuse me more, unless I'm trying to drive triangle screws. Only when I need to drive a triangle screw then I can look for the triangle screwdriver.

For the same reason you need weakref in Python, to handle circular references in memory managed via reference counting GC algorithm.

https://docs.python.org/3/library/weakref.html

Anyone that thinks Python is "simple", to come back to some of the suggestions on how it is easier than C++, they really should learn the language reference, standard library, and CPython FFI manuals.

One of the interesting things about C++ is that things that are language features in other languages are idioms in C++.

Maybe. Many people have tried, but only Rust has gotten anywhere close, and Rust can hardly be described as "not complex".

I'd say pointers are very rare in proper code.

Java deserve a lot of the credit for the happens-before concept that is the foundation of both its memory model and C++'s, but it can't express relaxed access and figuring out how to fit that in was a really big deal.

My understanding is that Consume is actually a desirable semantic that models what algorithms often want, and would allow for more optimization than Acquire if implemented properly, but that its failure was due almost entirely to it being difficult to implement correctly in compilers. In particular, the semantic is difficult to preserve across all compiler passes, especially given that existing compilers are essentially 20-40 years of accumulated optimizations that were never designed to preserve this semantic.

I sometimes wonder how difficult it would be for a compiler that was designed from the outset to implement Consume correctly.

... until you end up writing code that runs on ARM, which has weak memory ordering.

which turns out to be the vast majority of software, because contrary to what the author of the paper predicted, single thread performance ended up being more than good enough (and not the bottleneck)

Was Perl originally developed as the next iteration of either of those? Why are you being disingenuous?

The committee is part if ISO. Larger ISO shot down smaller ISO. Both are under the same system. WG21 is just the C++ subgroup of ISO.

The standard is the language. Again, you're arguing semantics.

The major compilers are certainly behind the latest standard as far as what they implement and if you're trying to run the latest and greatest you will find things that don't work.

You will find, though, that every major compiler considers those features that don't work either. Don't work because of bugs or they're not implemented yet. But either way, it's something they plan to implement.

Your objection reads like 1995. Of course, the C++ standard didn't exist until 1998, which is my point. Compilers have generally considered it a bug to not have all features implemented - the exception that proves the rule is export, which was removed from C++11 because all compilers agreed they weren't going to implement it.

The Python 2/Python 3 things was pretty startlingly horrifying. Not sure I would hold Python up as an exemplar.

It's early days for WebGPU. Safari only enabled it in version 26, so for most of the web it's only a year old. Give it time.

How many C++ implementations are there?

How many Python, D, Zig, Odin, etc. implementations are there?

And considering the number of users, only Python has an even measurable fraction of the number of C++ users.

BDFL neither scales nor perseveres. People have multiple things competing for their time and attention. They get old. They probably want to retire eventually. Eventually they die. If you want something to last more than a decade or two, BDFL is a poor choice.

> Or you do the BDFL model like Python, D, Zig, Odin, etc.

Python doesn't have a BDFL[1] and the others are toys.

1: Guido stepped down in 2018 and stopped involvement entirely in 2020 after an extended conflict with the community at large over PEP 572

over-obsession with the language's aesthetics ignore that the type system / borrow checker / ... are good and legitimately assist with development and did so even before the widespread use of LLMs.

many of those who ended up as Rust developers came from C and C++, seeing improvement from what they were using.

languages have been designed more and more to allow for higher level behaviours, in Rust's case, although not pursuing psuedocode, generally allows for very high level abstractions. regardless the computer still has to run things, languages are typically deterministic in their handling and psuedocode leaves much undetermined, unfully specified.

> I tend to wonder, in an alternate reality, where the buck stopped at C for systems languages, would we be better off because more people would use it and know how to fix memory related issues?

No, because what people don't realize is there is a constant influx of people who are new to C and don't know how to use it and how to fix memory related issues, so you can't just train everyone to not do them -- newbies by definition are untrained. The only winning move is to encode best practices into the compiler to make it hard for newbies to load the footguns, and only put them behind a bunch of warnings and features that experts can navigate.

> I tend to wonder, in an alternate reality, where the buck stopped at C for systems languages, would we be better off because more people would use it and know how to fix memory related issues?

I think that period has arguably already come and gone. C and C++ have been the most popular systems languages for decades. I think it's clear that mere popularity is not sufficient to produce memory-safe software with those languages. If anything, those languages are experiencing somewhat of a renaissance these days and it's these more recent developments that end up producing improvements with regard to memory safety.

> I just wonder why don’t we just keep using C, C#, and Java? I mean the former two are memory safe, and they can do “unsafe” just like Rust.

Bit of a nitpick, but I think you meant "latter" instead of "former".

That aside, there's more to picking a language to use than just memory safety and the ability to perform "unsafe" operations. Take your pick from more technical reasons (zero-overhead FFI to C, low-level control over data structures/operations/runtime, etc.) and more "soft" reasons (language affordances/features, ecosystem, etc.).

> Another thing: why do we write pseudocode and not design languages to look like pseudocode?

Perhaps COBOL might be what you're looking for? :P

As with many things, language design is full of tradeoffs, particularly when you want to produce something that is not too unfamiliar to a certain audience. IIRC another factor is that languages that want to work well for "experts" will tend to favor different points on the design spectrum. Consider APL-family languages - those are completely incomprehensible to anyone not familiar with them, but that same terseness is highly valued by proficient practitioners and is something pseudocode-like (or even "regular" code-like!) could never replicate.