Raii is enough of a reason IMO, but templates, type safety, actual arrays, constexpr, and various modern changes to the language that allow for the compiler to optimise code (move semantics and RVO)

Those are all fantastic reasons to use relibc, the libc written in Rust, which has the additional benefit of already existing.

https://gitlab.redox-os.org/redox-os/relibc

Sorry I missed this reply. I do'nt disagree, but honestly at this point anything is better than using C for libraries like this.

Function overloading and more places to use default values was enough to make me go mental last time I had to use strict C as opposed to limited C++

On a related note, Microsoft has also talked about refactoring their C run time to be written in C++. They give some reasons like maccard mentions I a comment next to this: features like RAII and templates make code easier to maintain than manual memory management and ifdefs.

https://devblogs.microsoft.com/cppblog/the-great-c-runtime-c...

Easy, C++ is more type safe than C since forever. Also the same reasoning why GCC has migrated to C++.

Microsoft has done the same with their new C runtime, and they have written a couple of blog posts exactly about that subject.

From "The Great C Runtime (CRT) Refactoring"

> So, as part of this great refactoring of the CRT, we have done an enormous amount of work to simplify and improve the quality of the code, so that it is easier to add features and fix bugs in the future. We have converted most of the CRT sources to compile as C++, enabling us to replace many ugly C idioms with simpler and more advanced C++ constructs. The publicly callable functions are still declared as C functions, of course (extern "C" in C++), so they can still be called from C. But internally we now take full advantage of the C++ language and its many useful features.

-- https://devblogs.microsoft.com/cppblog/the-great-c-runtime-c...

"C Runtime (CRT) Features, Fixes, and Breaking Changes in Visual Studio 14 CTP1"

https://devblogs.microsoft.com/cppblog/c-runtime-crt-feature...

"Introducing the Universal CRT"

https://devblogs.microsoft.com/cppblog/introducing-the-unive...

The Microsoft C standard library implementation also takes this approach - C++ implementation with C exports, for the reasons called out by the sibling comments.

This project is dead in the water if the resulting libc depends on libc++ at runtime.

I wondered if that’s why the proposal words it as “use C++ language facilities” instead of just “use C++” – use the C++ language, but not its stdlib.

I found this internal file that forms the basis of all the atoi and strol family functions. Seems like they do get some nice wins from the C++ language, without needing (e.g.) STL: https://github.com/llvm/llvm-project/blob/main/libc/src/__su...

As somebody else has already said, the idea is to use the c++ language and not its runtime or the standard library. In fact, there are a few clang-tidy checks for llvm libc to protect from accidentally using pieces from other libraries (like the system libc and the c++ standard library.) https://clang.llvm.org/extra/clang-tidy/checks/llvmlibc-call... https://clang.llvm.org/extra/clang-tidy/checks/llvmlibc-impl... https://clang.llvm.org/extra/clang-tidy/checks/llvmlibc-rest...

Systems like game consoles or Fuchsia only need a libc for POSIX compatibility, this would work well for them.

Many others have already trailed this path like e.g. Microsoft in 2014.

It’s much easier to write safer code in C++ than in C. You can still shoot yourself in the foot, but unlike C, modern C++ at least helps you avoid that.

If safety is a concern they would have gone the Rust route though. Is C++ easier to fuzz and statically analyze than C? I'd doubt that tbh.

Or Ada. I wish AuroraUX was still alive. :(

I would say that you need to know alot more to get to the point where writing C++ is easier than C, though.

Other than platform support I think C is practically only a hindrance compared to C++ in the hands of competent developers.