The preprocessor is such a botch (charitably, state of the art 1975). As Stroustrup said to me once in a discussion on the topic, "Once an ecological niche has been colonized it's almost impossible to clean up, so you have to work around it."
Yeah, but they're trying to replace it with more botch. "If constexpr can be used to precompute statically-determinable logic, except except except..."
Constexpr can replace most per-processor macros in a subset of C++. This is a huge improvement over preprocessor macros and functions which are very difficult to refactor. Even if it turns out to be 'botch', we can reason about the 'botch' and find ways to mitigate problems with it through static analysis.
We already have the preprocessor, and additional abstractions carry more than linear cost. I'm dissatisfied with these half-measure patches on static-time code evaluation.
Mostly the fact that the preprocessor doesn't go away. I still need it for the include system, I still need it for string interpolation, the file and line macros...
The goal is to get rid of this using C++20 modules (and potentially reduce compile times due to repeated expansion of header files).
> the file and line macros
This is addressed by C++20's std::source_location [0]
> I still need it for string interpolation
If you mean the `#` macro operator, then yeah that is still needed.
The point is to provide ways of doing these tasks that don't require a weird text replacement macro language and instead do them with C++. Obviously due to legacy codebases the preprocessor is going to stick around.
Yes. My biggest frustration with c++ as a language is that there are often two ways to do things: the right way, and the way you will find in tutorials and codebases because the right way didn't exist yet when they were written. This means the cognitive load to use the language in any context that isn't "greenfield project with experts" is significant relative to other languages.
> Doesn't mean you have to be stuck actually using them forever and ever
If I'm writing new code, probably not. But since it's a 40+ year old language, I'm doing more comprehension, maintenance, and extension of old code than writing new, and every new feature makes that task harder over time.
To be honest, if that happened I'd be 100% on board. My issue is combinatoric complexity, not a new way to do things. I'm not frustrated that we have constexpr; I'm frustrated I now have to worry about how it interacts with macros and namespaces and lifetimes and oh what if the values are templates and so on.
Each feature adds superlinear cost to understanding the language and the code you're reading.
It does, because many delivery projects chose languages based on the product SDKs, so if it isn't in the box, they don't come into the discussion at all.
Also in the meantime, most of the cool stuff in D is showing up on the languages that come on those SDKs (C++, Java, C#), weakening the argument to look outside of SDK supported languages.
Doesn't matter if D had it first, or if it has a better implementation, worse is better, when ecosystem, tooling, IDE and technical support are part of the equation.
All of my many products are commercial. I mostly have freedom to choose language. But I am also my own software development company and I have never felt brave enough to leave my client/s with the mountain of D code and no one to help after I went to develop next product somewhere else. This is very unfortunate.