Modified C++
Inspired by the paper "Some Were Meant for C" by Stephen Kell, I decided to show that it's possible to iterate C++ to be safer, more explicit, and less error-prone.
Here's a possible starting point: I didn't invent a new language or compiler, but took the world's best compiler, clang, and modified it to begin iterating towards a new furture of C++. Naming things is hard, so I call this 'Modified C++'. Some of the following could be implemented as tooling in a linter or checker, but the idea is to update the compiler directly. I also wanted to learn more about clang. This compiler needs a flag to enable/disable this functionality so that existing library code can be used with a 'diagnostic ignored' pragma.
You can build clang using the normal non-bootstrap process and you'll be left with a clang that compiles C++ but with the following modifications:
- All basic types (excluding pointers and references) are const by
default and may be marked 'mutable' to allow them to be changed after
declaration
- Lambda capture lists must be explicit (no [&] or [=], by themselves)
- Braces are required for conditional statements, case and default
statements within switches, and loops
- Implicit conversions to bool are prohibited (e.g., pointers must be
compared against nullptr/NULL)
- No goto support
- Explicit 'rule of six' for classes must be programmer-implemented
(default, copy, and move c'tors, copy and move assignment, d'tor)
- No C style casts
Here's an example program that's valid in Modified C++:
mutable int main(int, char**)
{
mutable int x = 0;
return x;
}
Here's another that will fail to compile:
mutable int main(int, char**)
{
int x = 1;
x = 0; // x is constant
return x;
}
I'd like your feedback. Future changes I'm thinking about are:
- feature flag for modified c++ to enable/disable with 'diagnostic ignored'
pragma, to support existing headers and libraries
- support enum classes only
- constructor declarations are explicit by default
- namespaces within classes
- normalize lambda and free function syntax
- your ideas here
If you're not changing how const works, then this has limited utility in C++ because C++ const has all sorts of problems (e.g. not transitive). Also, what does the "mutable" annotation for a free function (i.e. main) mean? That just seems weird.
> - Lambda capture lists must be explicit (no [&] or [=], by themselves)
[&] is pretty valuable in cases where you do something like invokeSynchronously([&] {...})
I don't know that your changes will ever see much adoption because it won't be able to compile anything more complex than a "hello world" program as all the things you disallow are used & the porting effort is not cosmetic. Additionally, you're not actually fixing any of the problems people have with C++. So:
1. Consider fixing const semantics if you're going down the path of defining a new language
2. Think about how to fix memory safety and issues around UB which are the #1 sharp edges for C++
I don't know if you're achieving the goal of a safer, less error-prone language with the changes outlined. Have you looked at the things Carbon [1] is doing? I'd say that's an attempt to define a spiritual successor to C++, one that can easily interoperate with C++ but when you stay within the language it's safer.
[1] https://github.com/carbon-language/carbon-lang