The C++ Standards Committee Deprecation Two-Step
Description
A four-panel comic strip in a medieval setting that satirizes the C++ language standards process. In the first panel, a character in orange robes looks through a spyglass from a castle wall and declares, 'We're dropping the ancient crap.' The adjacent panel shows a man in a blue tunic operating a large wooden winch, releasing a heavy mechanism, with a speech bubble above him saying, '(deprecated in C++20).' The third panel shows the original two characters looking panicked, with the one in orange saying, 'We're about to get killed.' The final panel mirrors the second, but now the man is struggling to reverse the winch, with a new speech bubble reading, '(undeprecated in C++26).' The meme humorously critiques the C++ standards committee for deprecating features that seem obsolete ('ancient crap') but are later discovered to be critical, forcing them to reverse the decision in a future standard. This scenario is relatable to senior C++ developers who have witnessed the language's sometimes turbulent evolution and the real-world consequences of removing long-standing, albeit arcane, features
Comments
18Comment deleted
Deprecating a C++ feature is like removing a load-bearing brick from a medieval castle because it doesn't look modern. It's all fine until you realize that brick was the only thing holding up the entire concept of 'memory safety'
Nothing says “committee consensus” like shipping a removal in C++20 and rediscovering ten million lines of COBOL-tier templates still depending on it by C++26
After 20 years in the industry, you realize the C++ committee's deprecation warnings are like production alerts at 3am - they'll definitely wake you up, but by the time you've refactored everything, they've already rolled back the change and now your 'fix' is the problem
When the C++ standards committee plays 'musical chairs' with language features, but the music is a 6-year deprecation cycle and the chairs are your production codebase. Nothing says 'stable ABI' quite like features that get deprecated in C++20 only to be undeprecated in C++26 - because apparently even the committee couldn't decide if that ancient crap was actually crap or just misunderstood genius. Meanwhile, your CI/CD pipeline is having an existential crisis trying to figure out which compiler flags to use
Deprecating C++ relics feels victorious - until 'unexpected' UB activates the blade mid-merge to main
WG21’s deprecation policy is basically a two‑phase commit: mark it deprecated in C++20, discover half of prod depends on it, then roll back in C++26 for eventual consistency with reality
In C++, deprecation is basically a feature flag for committee panic: ship the warning, watch half of finance fail to compile, then flip it back before the ABI freeze
What are these features (deprecated in C++20, to be restored in C++26)? Comment deleted
Asking serious question in meme channel? What are you, a real dev who ain’t just pretending to be one? 🤔 Comment deleted
https://en.cppreference.com/w/cpp/memory/polymorphic_allocator/destroy Comment deleted
What the actual fuck Comment deleted
according to undeprecating PR, it was not garbage rather API contract respect Comment deleted
I'm pretty sure admin asks the latest ClosedAI model to generate memes with only a general direction, and this is one of relatively good results Comment deleted
Are you for real? 😭 Comment deleted
I'm pretty sure admin never asked Threads FE devs for that🤯 Comment deleted
I think of my future granchildren...maybe their grandchilren will see full support of modules from C++20 A man can dream... Comment deleted
Scientists assert that a person was already born that will one day witness it. Comment deleted
Feature just went on sabbatical 🌚 Comment deleted