Another point to mention (which I think adds to the conclusion) is that by losing compatibility with the C preprocessor you'd lose compatibility with, well, C.
This means breaking of both C++ code that uses C libraries legitimately and "C++" code that's actually C with new/delete (or "the horror" as we put it).
All other languages wanting to interface with C seem to be using libffi or something. Currently C++ gets a shortcut, but in the future maybe it could go through an FFI.
It'd still be compatible with C from libraries, just not source. Those libraries would have to ship header files free of macros of course.
Losing backwards compatibility is usually a price to pay, not an objective. As an example, Python 3k chose to lose partial compatibility to 2.7 in order to change some parts of the language. While the user and maintainer community still debates if the change itself was a good decision (a different discussion IMO...), probably most will agree that the incompatibility bit has been and will be for some time a source of pain.
Meaning of auto, export templates, exception specifications were the biggest ones, there a few minor ones as well.
If you did want to do this, you'd run a C processor on the C code first.
Thankfully C++ no longer needs it to gain market share, it can stand on its own, while cleaning up the warts that caused unsafe code as a means of getting adopted.
#ifdef __cplusplus
extern "C" {
#endif
https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great...
"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."
Note the reference to ugly C idioms.
Also all major C compilers are written in C++, including clang and gcc, did you miss that as well?
CRT is an optional component of Windows software, a layer above ntdll and kernel32. Anyone can easily compile a program without C runtime library using /Zl compiler option. In this case, only Win32 and native API functions will be available, but not functions like printf() or strcmp().
So latest versions of CRT could be rewritten in C++, but this has nothing to do with documented OS API or even low-level undocumented native API, which are both still pure C.
https://msdn.microsoft.com/en-us/library/jj620896(v=vs.110)....
C code is considered legacy by Microsoft with C++ being the official systems programming language, hence why they dropped support for newer C versions, except for what is required by ANSI C++ standard.
https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...
Our focus in Visual C++ is on making a world-class C++ compiler
Our primary goal is to support "most of C99/C11 that is a subset of ISO C++98/C++11."
We do not plan to support ISO C features that are not part of either C90 or ISO C++.
Also the future of Windows lies on UWP, and C is certainly not a way of writing UWP APIs, unless one enjoys low level COM Windows 95 style.
Finally, the remaining C code is slowly being migrated to C++
https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...