rerdavies

I would be worried about transformation via LLM being considered a "trivial transformation". Trivial transformations do not remove the original copyright.

All completely unsettled law at this point. And, as a general guiding principle, you do NOT want to be one of the people who pays millions in legal fees and court costs to find out, whether you are right or wrong.

Trivial has to be pretty trivial. Google was found by a jury to have infringed Oracle's copyright on 9 lines of source code (the RangeCheck function). Although that fact did get lost in surrounding rulings and appeals relating to a further 11,500 lines of API declarations. The legal criteria for what's trivial is subjective and not well defined at all. And the legal costs for finding out what is or is not trivial can easily run into millions of dollars.

If I were you, I would not copy even truly "trivial" amounts of code.

And now (and then) all major compilers have their own compiler-specific versions of export. Go figure.

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

I was actually really impressed with Swift, which seems very much like a C++ with all the historical cruft and awfulness removed.

On the other hand, LLMs can (and do) also find every mistake and fix it.

I'm not ashamed to admit that I occasionally ask my LLM to find and fix all the bugs in a file. And not ashamed to admit that it often does. Most usually algorithmic problems, not memory problems, fwiw, because I use modern C++.

And C++23. If only they had said no one more time.

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

Maye you need a better AI. Just sayin'. My AI (Claude) doesn't make mistakes. Ok. It doesn't always think strategically, or factor well. But it certainly doesn't struggle with language mechanics.

Modern best practice for C++ is to crank the warnings to maximum, and to treat warnings as errors. You absolutely should treat linter-like warnings as an error, because they invariably are. So you know.

Agree with that. I'm a veteran user of C++, and I'm constantly finding really nice idioms in AI-generated code that I end up using myself.

The source of the UB is dereferncing a null pointer. I don't think it's possible to obtain a null reference otherwise. I, on the other hand, ignore people who advise against using references for parameters that can't be nullable. Particularly const references, which provide potentially massive performance improvements, and are a core idiom in C++.

It's probably nice to know WHY you might need weak_ptr.

Most of us can't/won't be able to view a web page that isn't https with a valid certificate.

That's disappointing. :-( Fwiw, as I remember it, the message pump implementation was easy enough. presumably because it doesn't require symmetric transfers. The thread pool implementation was hell.

Marketing. Advertising is only one of the strategies that get used to market a product.

My brother worked for Proctor & Gamble, which is a company whose success is built entirely on the magical effect of advertising.

As part of his training he had to run an advertising campaign for a minor P&G shampoo brand. Training for a finance position, not a product management position! Why would you make somebody in finance handle marketing for a shampoo? Because they need to understand the fundamental mechanics that drive the business. There's no such thing as a good or a bad ad. The only thing that matters is that you flash the name of your product into peoples' primitive lizard brain over and over and over. Pantene, Pantene, Pantene, Pantene. People buy commodity products, and are willing to pay more, solely based on whether they recognize the name or not. Humans have no defense against this.

Above all, avoid googling for really expensive things.

That time where all the ads I got for months were ads for ridiculously expensive servers, after I had (out of curiosity) googled for "what is the most expensive server you can buy on ebay?"

Or the time when all I got was ads for military-grade cables and connectors for months, after having googled (out of curiosity) for something or another about submarines -- most likely something about the dud submarines that the UK had sold to the Canadian government.

Sure. But you would have had to use either a 3rd party coroutine library, or have written one yourselves to use coroutines.

C++20 provides the language feature only, and none of the libraries to use the feature. You can write your own library to use the C++20 feature, but the standard APIs are raw and brutally complex. There are 3rd party libraries to use coroutines, but they are not part of the C++20 standard.

C++23 provides a std::generator, which is indeed a great feature.

Finally, C++26 provides std::execution, and std::task, which finally makes the feature usable with only standard C++ feature, and provides facilities for executing coroutines on thread pools, or message pumps. Significant features and problems have been deferred to C++29.

I guess it's a fair point that coroutines have not been abandoned. But it's alarming that it will now take the better part of a decade for the feature to reach a sensible state (depending on how C++26 gets handled).

And failure to meet project requirements.

e.g. https://responsiblestatecraft.org/f-35-failure/

Having just read Stroustrup's paper (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p43...), I'm inclined to agree with it.

Stroustrup's objection of subversion of, and politicization of the "consensus" process seems pretty darned reasonable to me.

And having two major compiler implementers (Clang and Microsoft) among those opposed to the proposal seems like a very poor sort of consensus to me.

The decision to defer how contracts on virtual methods work until C++29 strikes me as particularly horrifying, and renders the feature completely unusable precisely at the point where it most needed (PIMPL classes where public methods are pure virtual, with implementation provided in a private derived class).

And reminds me of c++20 coroutines, for which we are still awaiting a usable implementation. I made the mistake of actually writing a wrapper library for c++ coroutines. A great feature, but only heroically usable in its c++20 incarnation. (I actually did use it in project, but was left wondering why anyone would actually release THAT feature without a supporting class library). Implementation details were shocking, and awful, and insufficiently specified. And I would be completely amazed if my wrapper library continues to work with C++26.

God willing, C++26 will provide an implementation that allows us to sanely use coroutines in message pumps and thread pools soon (such a great feature!), if the standards committee, God Willing, takes the right and good and sensible path of removing contracts from C++26 so that we can get the structured concurrency library.

All in all, I can't help wondering whether the C++ standard doesn't need "Experimental Features" like Java has. It's certainly interesting to see how The Who Must Not Be Named (Oracle) uses experimental features, some of which have existed in experimental status across four or five Java releases. C++20 coroutines and contracts would have been perfect candidates for "experimental C++ features", that can be tested and hardened and have breaking ABI changes made as necessary and appropriate.

> welcome a contracts design that is simple, and “marketed” as just a debug aid

The operative word would be "simple". It's hard to imagine that the feature would require 56 (!!) pages of specifications if the constness rule were omitted. Who the heck ordered that!!??

Is it unreasonable to draw a lesson from previous half-assed features that failed after ratification, and say enough is enough?

Personally, I find node_modules and package.json completely terrifying. A solution teetering on the brink of a catastrophic implosion. I have a moderate sized project that pulls in several hundred dependencies and dependencies of dependencies, any one of which could contain a supply chain attack when I upgrade my dependencies. Which I must do. Upgrading is not an option; but it's only a matter of time before I get hit.

I think the wumpus that's being chased is that contracts COULD evolve into a compile time check. I'd be much happier if they actually caught the wumpus before they start polluting the language with yet another baroquely complicated feature that gets abandoned before it actually becomes useful (e.g. coroutines, and modules). Or just keep it simple and give us a C++-sensible replacement for assert(), and avoid the rest of it. i.e. contract_assert without the word "contract" in it. That would be a nice feature.

So much for the long tail! The rate of decline after the advent of AIs is sobering. From 181,000 questions a month at the absolute peak, to less than a thousand a month now!

You need to go deeper. The problem wasn't shitty moderation; it was shitty gamification.

I've seen that too. Not that common, but it certainly happened more than it should. You get a point for close-dup-ing whether you're right or not.

Ironically, in my experience, the alternatives were crap because the people giving the answers were point seekers. Microsoft Tech Support forums come to mind, particularly. No problem with the questions. But significant concerns about the skills of the people giving the answers. Not sure why that is, and why SO managed to get something right when it came to getting quality answers. For a while, anyway.

> We become masters, by moving through being juniors.

Yes this! I found it painful to watch abuse being heaped upon obviously junior programmers. Points should have beem award for mentoring those on the path, not gratuitously rejecting their questions.

Combined with the problem that more correct questions, that were likely to produce more correct answers were closed for further comments when they were incorrectly close-dup-ed. So often you would find the correct answer in the brief window between when the question was asked, and when a member of the self-appointed moderator class had incorrectly close-dup-ed the question. So frustrating!

My personal hate-on for SO: forcing all answers, INCLUDING the code to be licensed under an awkward CC license. Yes, you were "allowed" to dual-license the code in your answer under a more permissive license that doesn't require attribution.

I tried adding an explicit dual license to the code in my answers; but moderators would any answer that tried to do that.

Not so much that I care about the copyright of my code; but more a question of whether I would find a lawsuit from SO on my doorstep because I had neglected to credit SO for three lines of code that somebody ELSE had contributed to SO. A very real problem, given that SO management after the takeover had shown itself to be not really trustable.