import std.stdio;

scope class Foo // Klasse Foo als scope markieren
{
  int a;
  this(int a)
  {
    this.a = a;
  }
  ~this()
  {
    writefln("~Foo.a=", a);
  }
}

class Foo2
{
  ~this() // Wird durch GC aufgerufen
  {
    writefln("~Foo2");
  }
}

void main(char[][] args)
{
  auto variable = new Foo2(); // auto nimmt den Typ vom Ausdruck zur rechten Seite an.
  // delete variable; // Objekt sofort löschen, andernfalls dem GC überlassen.
  variable = null; // Nicht wirklich nötig.

  scope Foo foo2 = new Foo(2);
  //Foo foo2 = new Foo(2); // Error: variable foo2 reference to scope class must be scope

  { // Neuen Bereich erschaffen
    scope Foo foo1 = new Foo(1);
  } // foo1 wird hier zerstört

} // foo2 wird hier zerstört

// Ausgegeben wird:
~Foo.a=1
~Foo.a=2
~Foo2

1. D hat eine kontext-unabhängige Grammatik. Das macht das Parsen von Sourcecode unheimlich schnell und die Implementierung eines D-Parsers ungemein einfach.


2. D hat volle Unicodeunterstützung. Niemand will sich mehr mit Codepages herumschlagen und es ist eine gute Sache für internationalisierte Applikationen.


3. D ist zwar nicht sourcekompatibel mit anderen Sprachen, aber man kann direkt zu C-Code linken (man muss nur die C-Headerdateien nach D konvertieren.) Direkte C++-Unterstützung wird es nie geben, da das einen kompletten C++-Compiler erfordern würde (Walter Bright sagte mal, dass er ca. 10 Jahre benötigte um einen C++-Compiler zu schreiben, der dem Standard entsprach). Man muss sich also einem C-Layer bedienen oder das COM-Feature von D verwenden.


4. Code wird nativ zu Objektdateien kompiliert und er ist mindestens genauso schnell wie C/C++. Man ist nicht abhängig von einer virtuellen Maschine.


5. Es gibt einen integrierten Garbagecollector. Den kann man sich in C++ zwar mühselig selbst installieren, aber wenn man über die Grenzen des eigenen Programmes Speicher weitergeben will, wird es knifflig (zugegeben: ich hab keine Erfahrung mit GC & C++, hab ich nur so gehört.) Wer denkt ein GC hat in einer systemnahen Sprache nichts zu suchen, der irrt. In zeitkritischem Code (wie Spiele oder Steuerung von Geräten) alloziert man den ganzen Speicher den man benötigt ohnehin schon von vornherein, malloc() & Co sind da genauso undeterministisch wie ein GC. In D kann man den GC selbst steuern, also für eine Zeit lang deaktivieren od. eine Aufräumung erzwingen (z.B. wenn ein Spieler mal Pause gedrückt hat.) Man kann natürlich auch weiterhin seinen Speicher explizit selbst verwalten mit malloc(), und mit dem Schlüsselwort scope kann man auch Klassen auf dem Stack allozieren und automatisch bei Scopeende zerstören lassen (RAII.) D lässt einem also völlig freie Hand was Speichermanagement angeht.


6. Statt der Trennung zwischen Headerdateien und Quelltexten gibt es Module, wie in Java. Wenn man seine Bibliotheken nicht mit ganzem Sourcecode ausliefern kann, dann kann man D-Interfacedateien generieren (*.di), die nur Deklarationen und inline-Funktionen enthält. Manche halten Headerdateien für eine gute Übersicht, aber das denke ich nicht. Es ist völlig unnötig zwei Dateien verwalten zu müssen, wenn es eine einzige mit Dokumentationskommentaren auch tut (die mit Ddoc oder doxygen extrahiert werden können.)


7. Templates sind um Welten besser als bei C++.


8. Design by Contract, Unittests, scope guards...