Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 9:22 UTC (Fri) by farnz (subscriber, #17727)
In reply to: Herb Sutter on increasing safety in C++ by khim
Parent article: Herb Sutter on increasing safety in C++

This isn't the same as "doesn't know the nuance". This is the equivalent of Rust saying "println!, eprintln! and the Debug and Display traits have been removed. You will need to manually replace them to update your code, and there is no automatic fixer".

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 11:43 UTC (Fri) by ianmcc (subscriber, #88379) [Link] (4 responses)

IOStreams will never be removed from C++ though. I doubt it will ever get deprecated, it can just coexist.

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 12:08 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

And therein lies the problem for any "safety" improvements in C++; if you merely deprecate the parts that aren't memory-safe, and allow them to coexist, people will stick with their old habits. If you remove them, then existing C++ breaks, and breaks badly, requiring people to relearn the language.

This is the challenge for any language trying to make a change that involves removing existing features that people make use of; do you remove those features and break existing users in the hope of attracting new ones, or do you leave them in place and risk people ignoring the change you want to make? Note that for memory-safety, not removing the features people use that are unsafe means that I can compile with any profile set and code that's not memory-safe will continue to compile without a diagnostic like it does today - and that's a big challenge that no language I'm aware of has an answer to (even Rust's editions don't fully answer this problem).

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 16:59 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

Switching on a safety profile should also switch on a "warn on deprecated features" flag.

Pain in the arse, but for anybody who is serious enough to switch on a safety profile, they should be prepared to deal with the fallout. As I've said before, when I inherited a dodgy codebase, I just slowly ratcheted up the warning level, fixing things as they came up, until it got rid of most of the bugs without me ever actually finding half of them ... :-)

Cheers,
Wol

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 18:50 UTC (Fri) by farnz (subscriber, #17727) [Link]

But the moment you start issuing a diagnostic for C++ features that the profile bans, you've reduced the value of the profile significantly; if you were willing to rewrite the codebase to fix the issues, the cost savings of "rewrite in C++ with safety profile, use a C++ without safety profile compiler for the bits that aren't yet fixed" aren't significant compared to "rewrite in Rust, use cxx.rs to allow you to keep reusing all the C++ code that's not yet rewritten".

If the "safety profile" idea had reached usable status before Rust reached 1.0, then it would have a decent chance; but it's competing against a social reality where the people most willing to change the way they work have moved to Rust over the last 8 and a bit years, and the longer it takes to arrive, the fewer people will be left willing to learn a new language called "C++ with safety profile" but not a new language called "Rust".

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 21:07 UTC (Fri) by roc (subscriber, #30627) [Link]

This is bad in its own way. Say you've worked on a large C++ project for a long time, and it uses streams, exceptions, the STL, header files and so on. Then you get a job working on another C++ project in a similar domain to your previous project --- should be fine, because you "know C++" right? But it turns out you have to learn modules, std::format, ranges, and whatever error handling patterns they use instead of exceptions --- just to write the same kind of code you were writing before. And we're not talking about corner cases, but features you use everywhere.

Herb Sutter's plans would add safety rules to that list.

I'm not saying it's overall bad to evolve the language in this way. It's probably overall good. But when you make these changes you need to be honest and admit that to some extent, you've forked the language and developer community.