named arguments, string interpolation, please stop.

[Hipreme]

On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:
> 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.

Named arguments surely was a pretty useful feature, not for any 
function, but for one which D was missing that even C had:
```c
struct A a;
a = (struct A){a: 50, b:100};
```

Before named arguments, you could only use that syntax if you 
were using in the same line of declaration:
```d
///compiles
A a = {
    a: 50, b: 100
};

///Does not
A a;
a = {
   a: 50, b: 100
}

```

Right now, it is possible to achieve that in any place:
```d
A a;
a = A(a: 50, b: 100);
```
To me, this was a big win already for making cleaner syntax code, 
specially inside configuration parts.

But I feel like obliged to completely agree with your position 
and also, am waiting for all the improvements you last commented 
on classes which looked like a big win with no code breakage.
Template inlining is fairly essential to D, specially because of 
the Range interface nature.