The problem that took him 5 years to fix in C++, I solved in a minute with D

[Ola Fosheim Grøstad]

On Thursday, 10 March 2022 at 18:47:51 UTC, Ali Çehreli wrote:
> To respond to another point in this thread, I am not 
> embarrassed to admit that I am emotional. I actually like to be 
> emotional. Thank you very much! :)

Well, I've never been emotional in these forums, except when some 
people recently objected to a no-war icon. I showed the icon to 
my daughter and told her that "when it matters technologists 
seize to be narrow-minded and see the bigger picture", then the 
disappointment in the D community's 
the-lets-not-take-a-stance-on-even-the-most-obvious-attitude 
surfaced and I had to apologise to her and let her know that the 
narrowmindedness of technologists actually is deep, they are 
usually not very good at seeing the bigger picture.

The only interesting thing about this thread in relation to C++ 
and constexpr is this: they have a process. When they add a new 
feature they introduce it in a minimal state, then wait for users 
to gain experience with it and extend bit by bit in subsequent 
versions. This is true for constexpr, coroutines and many other 
features.

This brings some advantages:

1. You are less likely to have to revert a design (which is a big 
no-no in C++).

2. Implementors can move in lock-step so that you have complete 
implementations after ~1 year across compilers (usually).

3. You can collect problems users experience and change course 
before you extend the feature.

4. The community needs time to figure out how to make good use of 
a feature, which is needed in order to come up with sensible 
extensions of the feature.

5. You can focus your expenses on things that there is a strong 
demand for and evolve in many directions concurrently.

This is all in line with good language evolution policies. D has 
string mixins and they require compile time string concatenation, 
without string mixins the demand for dynamic compile time string 
concatenation is not very high in the context of system level 
programming. So it made sense to first support a fixed container 
like array (high demand because of LUT building), wait with the 
addition of basic_string/vector to C++20, then we'll have to see 
if there are further improvements in C++23/26. I personally only 
need constexpr array in C++, and more frequently end up with my 
own string representations anyway (typical of lower level 
programming).

If you plan on using C++ for higher level programming than 
dsp/engines you'll be disappointed, but that disappointment goes 
much deeper than any individual feature. C++ cannot become a 
glorified scripting language, nor should it try to be. It should 
focus on the strong points it has, and so should D.

But D needs to learn something about process from C++. Take a 
step away from the 
the-lets-not-take-a-stance-on-even-the-most-obvious-attitude, get 
some clear focus and make priorities. You actually have to choose 
between:

1. slow conservative language evolution based on demand with no 
breaking changes

2. experimental language evolution based on creativity with 
breaking changes

D's current approach is "experimental language evolution based on 
creativity without breaking changes" and that is not a 
sustainable model in the long term.