The C++ Standard Library Has Been Walking Itself Back for Fifteen Years
hftuniversity.com> Every entry below points at a real paper that the working group adopted. None of these are arguments. They are admissions in writing.
I smell AI. If you don't write it, I don't read it.
> This is what fifteen years of standards work on a five-letter keyword ['volatile'] looks like.
How many letters are in the word 'volatile' ?
Woof. Didn't even bother to proofread the AI slop. Wow.
I think we need a "Flag AI Slop" button.
That's just the "Flag" button.
Itd be better if these domains were banned
Although it's AI, I am surprised how many references it added correctly.
don't care, it has all the right points
Better get used to it, the art of writing without AI assistance is dead. You will occasionally find some of it like a truffle in the woods, but that was it. And even if the next generation will attempt stringing a few sentences together by hand it will sound like AI, because they grew up spending more time talking to AI than anyone else.
I attend a local writer’s group in my area, where people write in person within a time limit. The art of writing without AI assistance still lives, but it’s not online and probably not discussing the C++ standard library.
If I want to read a LLM's "opinion" on some subject I just prompt it myself. Inserting humans as intermediaries that pretend they wrote something is dishonest at best. Future generations will hopefully see through that and stop sign generated texts with fake human names.
Really? When someone's already warmed the Earth slightly and used the energy and spent the tokens to do it once, you're going to do it again, just to spite them, because you hate the environment? And because you're rich and have unlimited tokens to spend on anything?
Using a cache of outputs makes sense, but that is just an optimization. I don't mind if a site publishes generated texts, as long as they are clearly labelled as such and have no fake-writer human names attached.
this kind of overt inevitabilism is complicity in the death of good writing.
Over in r/cpp there were interesting (presumably largely thought up by actual people not just spew from a model) ideas for language reform hiding as "Profiles" for C++ 29 or beyond
https://www.reddit.com/r/cpp/comments/1tja9zr/c_profiles_a_c...
Beyond just quite possibly being slop, this is also sloppy and confused: complaining that C++ cannot remove features because they live in the stdlib forever while listing out a bevy of features that got deprecated and then removed is just oof.
Also, fun fact: Rust cannot remove anything from std once stabilised, presumably forever. Take this with a slight grain of salt, I haven't vetted this thought myself, but it's what I hear from Rust project people and I've just been in the project all-hands for three days.
Rust does partially have an easier time since it eg. does not guarantee the ABI of various std types like Vec (although the size and alignment are probably guaranteed at this point), and with 1&mut XOR N& providing local reasoning and isolation you get to change internal details easier.
Rust promises not to remove things from the stdlib unless they're unsound. It does commonly deprecate things - the deprecation warnings won't bother people merely using your library or whatever but will still show for you if you're maintaining it.
I left C++ almost 10 years ago but I still remember how surprised and frustrated I was when auto_ptr was deprecated and then removed from the C++ standard as we had built our dependency injection framework and progress primitive on it.
Wasn't unique_ptr added as a migration path away from auto_ptr to provide similar functionality more safely? I've never used them but was just reading the history.
Sure, but auto_ptr is different in that copying transfers ownership, while unique_ptr prohibits copying.
But if I understand it right, auto_ptr assignment didn't actually copy the pointer, but instead moved it to a new variable and quietly made the original variable null? And unique_ptr made this operation require an explicit move() call, because the assignment-only style caused too many null pointer bugs.
I'm just curious about this for historical interest.
Yes, it was a design decision of the auto_ptr to have this move semantics and it worked very nicely for us because we used for instance to pass progress monitors down the stack.