What are the worst parts of D?

[eles via Digitalmars-d]

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:

> Right now I have no idea where the development is headed and 
> what to expect from next few releases. I am not speaking about 
> wiki.dlang.org/Agenda but about bigger picture. Unexpected 
> focus on C++ support, thread about killing auto-decoding, 
> recent ref counting proposal

Just to add more salt:

http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx

Raymond Chen: " When you ask somebody what garbage collection is, 
the answer you get is probably going to be something along the 
lines of "Garbage collection is when the operating environment 
automatically reclaims memory that is no longer being used by the 
program. It does this by tracing memory starting from roots to 
identify which objects are accessible."

This description confuses the mechanism with the goal. It's like 
saying the job of a firefighter is "driving a red truck and 
spraying water." That's a description of what a firefighter does, 
but it misses the point of the job (namely, putting out fires 
and, more generally, fire safety).

Garbage collection is simulating a computer with an infinite 
amount of memory. The rest is mechanism. And naturally, the 
mechanism is "reclaiming memory that the program wouldn't notice 
went missing." It's one giant application of the as-if rule."

Interesting, in the comments, the distinction that is made 
between finalizers and destructors, even if they happen to have 
the same syntax, for example in C# and C++.

For example here: 
http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx#10047776

I feel difficult to swallow the fact that D classes do not lend 
themselves to RAII. While I could accept the memory management 
could be left outside RAII, running destructors (or disposers) 
deterministically is a must.

I particularily find bad that D recommends using structs to free 
resources because the destructor of those is run automatically. 
Just look at this example:

http://dlang.org/cpptod.html#raii

struct File
{
     Handle h;

     ~this()
     {
         h.release();
     }
}

void test()
{
     if (...)
     {
         auto f = File();
         ...
     } // f.~this() gets run at closing brace, even if
       // scope was exited via a thrown exception
}

Even if C++ structs are almost the same as classes, the logical 
solit between the two is: structs are DATA, classes are BEHAVIOR. 
I will not get my head around the fact that I will *recommend* 
putting methods in a struct.