named arguments, string interpolation, please stop.

[deadalnix]

I have been in the D community for a very long time. I have seen 
D successfully deployed in companies, and the pain points 
associated with it. I have seen D fails to catch on in companies 
and why that is has well.

Let me tell you, none of this has anything to do with feature D 
has or does not have. At large, D has more features than most 
languages.

D chasing the next feature like a crack addict chase his next 
dose. With the same level of success.

The main problem people face with D in the real world are almost 
exclusively of the implementation kind. The list is endless (and 
yes, there are many bugs reports about these things). I recently 
made a post about how the OOP implementation is extremely sub-par 
vs what people in OOP languages would expect. no change of the 
language required to fix. See here: 
https://forum.dlang.org/post/hteuczyclxajakrisxjd@forum.dlang.org

But if you are not convinced, here are a few more example of 
thing being implemented wrong or existing feature not working 
right:
  - D runtime is unable to see thread started manually (for 
instance with pthread-create) leading to all kind of bizarre 
behavior.
  - Template symbols are generated as weak, which prevents 
inlining (!).
  - Pretty much no cross module inlining, making helper function 
absurdly costly.
  - scope(success) generates exception handling code.
  - D goes virtual by default for class methods, but LTO is unable 
to finalize (contrary to every other languages going virtual by 
default).
  - The GC implementation is nowhere close to where it needs to be.
  - in contracts are dynamically bound (and in the callee) instead 
of statically bounds and in the caller.

These are just simple thing that I have on top of my mind, but 
there are a ton more. I have seen some of the above cause 
projects to fail. None of them require any significant language 
change.

There is nothing features like string interpolations or named 
argument can bring to the table that could pay for the 
implementations problem of existing feature. The cost benefit 
analysis is just a big L for D: the fail to address the main pain 
points, while causing massive breakage in the tooling ecosystem 
(syntax highlighting support in 3rd party IDE, code formatter, 
etc...), and it cost real time and resource to upgrade these, or 
come at the cost of other quality of life stuff nullifying their 
benefit (for instance, the quality of syntax highlighting for D 
has degraded significantly in vim and sublime text over the past 
few years).

In addition, some recent D features, such as @nogc, has been a 
productivity disaster int he wild. While the impact might not be 
felt on smaller codebases, the infectious nature of the feature 
makes large codebase significantly harder the refactor than they 
used to be.

Each time we take steps in that direction, D becomes a harder 
sell.