(Back in C++20 days I had a terrible habit of finding bugs in MSVC's implementations of metaprogramming features, after they claimed to be feature complete on C++20. Probably because people use these features less. Even now I occasionally receive emails about those bugs they've finally fixed.)
The compiler writers have had a ton of issues implementing modules and aren't particularly excited for them (the committee seems to have forgot the lessens learned from c++98 and not having full implementations for crazy hard things)
on the other hand constexpr changes tend to be picked up pretty quickly, and a lot of them tend to be things that the compiler/stl authors themselves are asking for.
Since C++14 that I have increasingly changed my mind that it should only be about existing practice, and no paper should be accepted without implementation, regardless of how basic it may be, just like in other language ecosystems.
Yes it might prevent lots of cool features, yet how good are they if it takes years to be implemented across compilers, or they turn out to be yet another export template.
Additionally it would help to reduce count from those 300+ people, not everyone is there for good reasons, some only want to have a "contributed to C++" on their background, and then they are gone.
> should only be about existing practice, and no paper should be accepted without implementation
When c++11 was still c++0x they made a big song and dance about how they wouldn't do another export template boondoggle and wanted an implementation available for any features. Then they seemed to have completely forget about it when doing modules (which not that surprisingly is running into similar issues that export templates did).
Many features of D have since found their way into C++, such as ranges, compile time function execution, thousands separators in numeric literals, conditional compilation blocks, etc.
There's not only the features, but how they are done. D users regularly tell me that it is just so much easier to program in D. Aesthetics do matter.
I've pointed out many times that thousands markers in D came from Ada. However, no other language did them until D did.
Yes, Lisp has compile time function execution. Where it remained until D did it with a compiled language.
C++'s implementation of ranges is still based on pointers (an iterator pair), rather than based on arrays as in D. The language loses semantic information because there is no particular thing that connects the iterator pair as being the limits on an array. Basing ranges on arrays enables crucial things like array bounds checking.
Yes, D's contracts are based on Eiffel. But they also went nowhere until D adopted them.
Yeah, maybe they should have, would have been a lot simpler.
But C++ really wanted modules to be a more or less drop in replacement for #include (or at least a set of common use cases), which really pushed up the required level of complexity.
That it was already there via Apple and Google's work, header maps, but what we got was Microsoft proposal, after some collaboration with Google.
Note at WWDC 2024, the module improvements regarding build times, in what concerns C++, it is based on header maps as well. Apple is not even bothering with C++20 modules.
Modules implicate the entire toolchain, backward compatibility, and binary compatibility. constexpr is a compiler feature. Wild that they are being compared.
See how many years it takes for a compiler on average to be 100% compliant after a standard is ratified, not widely at all when one wants to write portable code, regardless.
In practice it's the same thing with C++ today as it is with web standards: you have to evaluate support on a feature-by-feature basis, and stick to the features that are supported on all the implementations you care about.
And constexpr in stdlib is much more likely to get quick adoption across all implementations than something like modules.
