Das ist das Ende von C++!

[KennerDesProblems]

Artchi schrieb:

Das kannst du vielleicht nicht wissen, aber die Win32-API ist eine C-API, nichts C++. Deshalb kann da schlecht eine String-Klasse benutzt werden. Aber ist ok. Das Beispiel habe ich nur aufgeführt, um zu zeigen, das eine API sehr wohl von einem Typ (in dem Fall char) auf einen aktuelleren/sinnvolleren Typ (in dem Fall wchar_t) umgestellt werden kann. Das C keine Klassen kennt, hat ja nichts mit C++ zu tun.

ich weiß

Langsam wird es lächerlich. Gibts doch endlich zu, dass C++ in Sachen standard library viel schlechter ist als Java.

Was hat den C++ für ne XML Unterstützung?

[Artchi]

KennerDesProblems schrieb:

Langsam wird es lächerlich. Gibts doch endlich zu, dass C++ in Sachen standard library viel schlechter ist als Java.

Ja, ich gebe hoch und heilig zu, das C++ in Sachen Standardlibrary der letzte Schrott in der Geschichte der Programmiersprachen ist.

Artchi

PS: endlich kann ich mich hier ausklinken.

[rüdiger]

Optimizer schrieb:

Ich denke mal nicht, dass die Entwickler von D denken, die perfekte String-Klasse entworfen zu haben. Ich würde mal vermuten, dass sie besser als std::string ist, aber den eigentlichen Vorteil sehe ich darin, dass dafür ein Sprachmittel zur Verfügung steht.

Ich verstehe den Ansatz von C++, möglichst viel auf Bibliotheksebene zu machen um die Sprache davon unabhängig zu haben. C++ soll irgendwie alles geil können, man soll damit Programme schreiben können oder sich auch selber mit Makros, umfangreicher Operator-Überladung und eben nicht fertigem foreach und Strings in der Sprache unglaublich erweitern und anpassen können. Ich denke wir beide haben da eine grundverschiedene Meinung. Ich denke, auf Sprachebene sind viele Dinge besser realisierbar, du befürchtest anscheinend, dass darunter die Vielseitigkeit einer Sprache leidet. Ich halte extrem vielseitige Sprachen aber für schlecht.

Die String-Klasse ist doch das beste Beispiel. Angenommen die wäre jetzt "hardgecodet", dann würde ich mich doch ziemlich ärgern, so eine String-Klasse hardgecodet zu haben. Wenn ich eben eine String-Klasse mit Multibyte-Support haben will, dann kann ich sie mir eben basteln und die Algorithmen der Standard-Library kommen damit trotzdem klar. Wäre std::string nun "fest verdrahtet", dann hätte ich ein großes Problem.

Skriptsprachen existieren auch oft nur aus dem simplen Grund, weil auf Sprachebene alles besser integrierbar ist. Nimm als Beispiel JSP. Es ist halt nicht toll, wenn man eine Webseite machen will und dann von irgendwelchen Servlet-Klassen ständig ableitet und Code schreibt -> man entwickelt für diesen Zweck ne eigene Sprache. Sinnvoll. Du dagegen argumentierst, die Sprache solle möglichst wenig eingebaut haben, damit sie vielseitig ist. Was ich nicht für sinnvoll halte, da sie dann zwar alles kann, aber nichts gescheit.

Ich kenne JSP nicht. Ich habe auch nichts gegen Spezial-Sprachen (nur dass die die ich kenne oft sehr schludrig sind, wie zB PHP). Nur finde ich eine vielseitige Programmiersprache nicht schlecht, weil ich so leichter Mängel der Sprache ausgleichen kann oder wenn sich meine Anforderungen ändern, dann kann ich mit der Programmiersprache reagieren.

C++ kann kein gescheites foreach und keine gescheiten Strings.

Warum kann C++ keine gescheiten Strings? Weil "abc".length(); nicht funktioniert? Welche Programmiersprache hat dann gescheite Strings? Ruby und mehr nicht? Und können Java und C++ auch keine gescheiten Integer, weil 10.sqrt() nicht funktioniert?

Wenn du verschiedene Bibliotheken nutzt, die ihre eigenen String-Klassen mitbringen bist du immer irgendwie dabei, über char[] hin und her zu konvertieren.

Die Bibliotheken, die eigene String-Klassen mitbringen haben ja in der Regel auch ein Kohärentes String-Design. Also muss ich nicht viel hin und her konvertieren und wenn, dann bietet mit C++ eben die Mittel um da entsprechend drauf zu reagieren.

Oder bastel doch mal ein foreach. Es wird niemals genau so geil sein wie

foreach( int myInt in myIntList )
    sum += myInt;

Und mit foreach ist es das selbe wie mit String. Jeder bastelt sich sein eigenes...

Ich kenne C# nicht genug, um zu wissen wie dort foreach gehandhabt wird. Aber was muss ich machen, damit meine Klasse auch in foreach benutzt werden kann?

... und würde die Sprache verkomplizieren.

Nein, die Grammatik der Sprache wäre gleich kompliziert und der Umgang mit der Sprache wäre ganz erheblich einfacher.

Ich habe ja auch nie behauptet, dass die Gramatik der Sprache wesentlich schwieriger wird.

[rüdiger]

KennerDesProblems schrieb:

Was hat den C++ für ne XML Unterstützung?

Eine sehr gute.

[nep]

Ich finde den Ansatz von C++ an sich ja eigentlich auch nicht schlecht, dass man erst mal nur die Sprache an sich und eine eher kleine Standardbibliothek hat. Wenn nun die ganzen Bibliotheken die es da draußen gibt den Standard so weit wie möglich ausnützen würden, dann wäre das eine richtig feine Sache. Zum Großteil ist es aber leider nicht so, also relativiert sich das ganze halt leider auch wieder.

Ich kenne C# nicht genug, um zu wissen wie dort foreach gehandhabt wird. Aber was muss ich machen, damit meine Klasse auch in foreach benutzt werden kann?

Ich kenn mich in C# zwar auch nicht wirklich aus, aber in Java ist das relativ einfach, da muss deine Klasse einfach das Interface Iterable implementieren, mehr nicht. Ich denke mal in C# wird es ähnlich sein.

[Tipp]

Don't feed the troll.

[daHa]

wie hier
http://www.digitalmars.com/d/comparison.html
zu sehen ist, ist D nicht nur das ende von C++ sondern auch von Java und C#
kann viel mehr und ist viel neuer

[Kenner der Sprachen]

Und Brainfuck ist das Ende von D.

[ten]

Artchi schrieb:

Ja, ich gebe hoch und heilig zu, das C++ in Sachen Standardlibrary der letzte Schrott in der Geschichte der Programmiersprachen ist.

na, endlich bringt's mal einer auf den punkt!

rüdiger schrieb:

KennerDesProblems schrieb:

Was hat den C++ für ne XML Unterstützung?

Eine sehr gute.

welche?

[Gast]

Was mir an D gefällt sind die Bezeichner für die einzelnen Datentypen. Kein unsigned long long sondern einfach nur ulong. Wobei ich die Bezeichner aus stdint.h (uint64_t) trotzdem besser finde.

[daHa]

Kenner der Sprachen schrieb:

Und Brainfuck ist das Ende von D.

brainfuck wurde von Ook! beendet

[ten]

TactX schrieb:

Was mir an D gefällt sind die Bezeichner für die einzelnen Datentypen. Kein unsigned long long sondern einfach nur ulong. Wobei ich die Bezeichner aus stdint.h (uint64_t) trotzdem besser finde.

geht noch besser: u64, u32, i8 usw...

[Gast]

rüdiger schrieb:

Optimizer schrieb:

Ich denke mal nicht, dass die Entwickler von D denken, die perfekte String-Klasse entworfen zu haben. Ich würde mal vermuten, dass sie besser als std::string ist, aber den eigentlichen Vorteil sehe ich darin, dass dafür ein Sprachmittel zur Verfügung steht.

Ich verstehe den Ansatz von C++, möglichst viel auf Bibliotheksebene zu machen um die Sprache davon unabhängig zu haben. C++ soll irgendwie alles geil können, man soll damit Programme schreiben können oder sich auch selber mit Makros, umfangreicher Operator-Überladung und eben nicht fertigem foreach und Strings in der Sprache unglaublich erweitern und anpassen können. Ich denke wir beide haben da eine grundverschiedene Meinung. Ich denke, auf Sprachebene sind viele Dinge besser realisierbar, du befürchtest anscheinend, dass darunter die Vielseitigkeit einer Sprache leidet. Ich halte extrem vielseitige Sprachen aber für schlecht.

Die String-Klasse ist doch das beste Beispiel. Angenommen die wäre jetzt "hardgecodet", dann würde ich mich doch ziemlich ärgern, so eine String-Klasse hardgecodet zu haben. Wenn ich eben eine String-Klasse mit Multibyte-Support haben will, dann kann ich sie mir eben basteln und die Algorithmen der Standard-Library kommen damit trotzdem klar. Wäre std::string nun "fest verdrahtet", dann hätte ich ein großes Problem.

Was für ein Problem hättest du denn genau? Ich sehe keines. Angenommen, du hast wirklich anfangs ohne Multibyte-Support geplant und änderst die Klasse nachträglich... was funktioniert dann nicht mehr genau wegen dem, dass "abc" eine Instanz deiner String-Klasse ist?

Skriptsprachen existieren auch oft nur aus dem simplen Grund, weil auf Sprachebene alles besser integrierbar ist. Nimm als Beispiel JSP. Es ist halt nicht toll, wenn man eine Webseite machen will und dann von irgendwelchen Servlet-Klassen ständig ableitet und Code schreibt -> man entwickelt für diesen Zweck ne eigene Sprache. Sinnvoll. Du dagegen argumentierst, die Sprache solle möglichst wenig eingebaut haben, damit sie vielseitig ist. Was ich nicht für sinnvoll halte, da sie dann zwar alles kann, aber nichts gescheit.

Ich kenne JSP nicht. Ich habe auch nichts gegen Spezial-Sprachen (nur dass die die ich kenne oft sehr schludrig sind, wie zB PHP). Nur finde ich eine vielseitige Programmiersprache nicht schlecht, weil ich so leichter Mängel der Sprache ausgleichen kann oder wenn sich meine Anforderungen ändern, dann kann ich mit der Programmiersprache reagieren.

Ja, ich denke auch, dass eine Programmiersprache schon ein bisschen vielseitig sein sollte. Kein extrem ist gut. Aber das Ziel mit einer Sprache fast alles gut machen zu können ist nicht haltbar. (btw. JSP ist in erster Linie HTML ähnlich, aber man kann eigene Tags entwerfen, die man selber wiederum in JSP oder in Java schreibt. Ist halt sehr sinnvoll für Webdesign, diese Sprache hat ein konkretes Anwendungsgebiet wo sie gut ist).

C++ kann kein gescheites foreach und keine gescheiten Strings.

Warum kann C++ keine gescheiten Strings? Weil "abc".length(); nicht funktioniert? Welche Programmiersprache hat dann gescheite Strings? Ruby und mehr nicht? Und können Java und C++ auch keine gescheiten Integer, weil 10.sqrt() nicht funktioniert?

Was ganz konkret dort geht ist ein Literal eines solchen Typs hinzuschreiben. In C++ ist es schon wieder mit einem Konstruktoraufruf verbunden, einer String-Variable ein String-Literal zuzuweisen. Dagegen zum Beispiel in Java ist "abc" eine Instanz von String, ohne Typumwandlung, ohne Konstruktion ohne alles lässt sie sich anderen String-Variablen zuweisen. In C++ wäre das äquivalent:

const char* myString = "abc";

Die Strings auf Sprachebene sind eben keine std::strings. Es hat halt Vorteile, Strings auf Sprachebene zu haben.

Was die Integer angeht: Man kann natürlich Literale hinschreiben. Literale sind grundsätzlich eigentlich Dinge, die man so nicht braucht. Trotzdem integriert man sie auf Sprachebene für besonders wichtige Typen. In den meisten Sprachen sind Strings wichtig.
Dass die Integer keine Methoden haben finde ich dagegen weniger schlimm. In C# sind Integer übrigens (zumindest scheinbar) auch Strukturen, die Methoden haben.

Oder bastel doch mal ein foreach. Es wird niemals genau so geil sein wie

foreach( int myInt in myIntList )
    sum += myInt;

Und mit foreach ist es das selbe wie mit String. Jeder bastelt sich sein eigenes...

Ich kenne C# nicht genug, um zu wissen wie dort foreach gehandhabt wird. Aber was muss ich machen, damit meine Klasse auch in foreach benutzt werden kann?

Du musst ein Interface implementieren und einen passenden Enumerator schreiben. In C# 2.0 gibt es ein Sprachmittel für Enumeratoren, so dass man diese Klasse nicht mehr selber definieren muss:

public class Stack<T> : IEnumerable<T> {
        public IEnumerator<T> GetEnumerator()
        {
            for (int i = top; --i >= 0; )
            {
                yield return values[i];
            }
        }

        // Dass man dies braucht ist ein Design-Fehler aus alten Tagen  :-(
        IEnumerator IEnumerable.GetEnumerator()
        {
            return GetEnumerator();
        }
}

... und würde die Sprache verkomplizieren.

Nein, die Grammatik der Sprache wäre gleich kompliziert und der Umgang mit der Sprache wäre ganz erheblich einfacher.

Ich habe ja auch nie behauptet, dass die Gramatik der Sprache wesentlich schwieriger wird.

Ok. Was meinst du, würde komplizierter werden?

[Gast]

Function Templates  	Yes  	No  	Yes  	No  	Yes

Ich möchte jetzt mal nicht auf den Begriff Template rumreiten. Versteht jemand, was die Seite genau damit meint, was Java haben soll und C# nicht?

[Zeus]

Naja bei den Vergleich scheind DM mit Falschinformation zu glänzen.
In C++ kann ne Klasse ein Referenttype oder Werttype sein, oder?

[rüdiger]

Optimizer schrieb:

rüdiger schrieb:

Optimizer schrieb:

Ich denke mal nicht, dass die Entwickler von D denken, die perfekte String-Klasse entworfen zu haben. Ich würde mal vermuten, dass sie besser als std::string ist, aber den eigentlichen Vorteil sehe ich darin, dass dafür ein Sprachmittel zur Verfügung steht.

Ich verstehe den Ansatz von C++, möglichst viel auf Bibliotheksebene zu machen um die Sprache davon unabhängig zu haben. C++ soll irgendwie alles geil können, man soll damit Programme schreiben können oder sich auch selber mit Makros, umfangreicher Operator-Überladung und eben nicht fertigem foreach und Strings in der Sprache unglaublich erweitern und anpassen können. Ich denke wir beide haben da eine grundverschiedene Meinung. Ich denke, auf Sprachebene sind viele Dinge besser realisierbar, du befürchtest anscheinend, dass darunter die Vielseitigkeit einer Sprache leidet. Ich halte extrem vielseitige Sprachen aber für schlecht.

Die String-Klasse ist doch das beste Beispiel. Angenommen die wäre jetzt "hardgecodet", dann würde ich mich doch ziemlich ärgern, so eine String-Klasse hardgecodet zu haben. Wenn ich eben eine String-Klasse mit Multibyte-Support haben will, dann kann ich sie mir eben basteln und die Algorithmen der Standard-Library kommen damit trotzdem klar. Wäre std::string nun "fest verdrahtet", dann hätte ich ein großes Problem.

Was für ein Problem hättest du denn genau? Ich sehe keines. Angenommen, du hast wirklich anfangs ohne Multibyte-Support geplant und änderst die Klasse nachträglich... was funktioniert dann nicht mehr genau wegen dem, dass "abc" eine Instanz deiner String-Klasse ist?

Das Problem ist, das ich es nicht ändern kann. Das kann nur der Hersteller der Implementierung oder gar des Standards. Das sind ja nicht nur Sachen wie Multibyte, sondern auch die Breite der Zeichen bei Fixed-Byte-Sachen etc.

Skriptsprachen existieren auch oft nur aus dem simplen Grund, weil auf Sprachebene alles besser integrierbar ist. Nimm als Beispiel JSP. Es ist halt nicht toll, wenn man eine Webseite machen will und dann von irgendwelchen Servlet-Klassen ständig ableitet und Code schreibt -> man entwickelt für diesen Zweck ne eigene Sprache. Sinnvoll. Du dagegen argumentierst, die Sprache solle möglichst wenig eingebaut haben, damit sie vielseitig ist. Was ich nicht für sinnvoll halte, da sie dann zwar alles kann, aber nichts gescheit.

Ich kenne JSP nicht. Ich habe auch nichts gegen Spezial-Sprachen (nur dass die die ich kenne oft sehr schludrig sind, wie zB PHP). Nur finde ich eine vielseitige Programmiersprache nicht schlecht, weil ich so leichter Mängel der Sprache ausgleichen kann oder wenn sich meine Anforderungen ändern, dann kann ich mit der Programmiersprache reagieren.

Ja, ich denke auch, dass eine Programmiersprache schon ein bisschen vielseitig sein sollte. Kein extrem ist gut. Aber das Ziel mit einer Sprache fast alles gut machen zu können ist nicht haltbar. (btw. JSP ist in erster Linie HTML ähnlich, aber man kann eigene Tags entwerfen, die man selber wiederum in JSP oder in Java schreibt. Ist halt sehr sinnvoll für Webdesign, diese Sprache hat ein konkretes Anwendungsgebiet wo sie gut ist).

Ich denke, dass es universelle Programmiersprachen gibt, die alles gut können. C++ gehört da aber nicht zu.

C++ kann kein gescheites foreach und keine gescheiten Strings.

Warum kann C++ keine gescheiten Strings? Weil "abc".length(); nicht funktioniert? Welche Programmiersprache hat dann gescheite Strings? Ruby und mehr nicht? Und können Java und C++ auch keine gescheiten Integer, weil 10.sqrt() nicht funktioniert?

Was ganz konkret dort geht ist ein Literal eines solchen Typs hinzuschreiben. In C++ ist es schon wieder mit einem Konstruktoraufruf verbunden, einer String-Variable ein String-Literal zuzuweisen. Dagegen zum Beispiel in Java ist "abc" eine Instanz von String, ohne Typumwandlung, ohne Konstruktion ohne alles lässt sie sich anderen String-Variablen zuweisen. In C++ wäre das äquivalent:

const char* myString = "abc";

Die Strings auf Sprachebene sind eben keine std::strings. Es hat halt Vorteile, Strings auf Sprachebene zu haben.

Da sehe ich noch keinen Vorteil. In C++ ist

std::string myString = "abc";

doch auch möglich.

Was die Integer angeht: Man kann natürlich Literale hinschreiben. Literale sind grundsätzlich eigentlich Dinge, die man so nicht braucht. Trotzdem integriert man sie auf Sprachebene für besonders wichtige Typen. In den meisten Sprachen sind Strings wichtig.
Dass die Integer keine Methoden haben finde ich dagegen weniger schlimm. In C# sind Integer übrigens (zumindest scheinbar) auch Strukturen, die Methoden haben.

Und warum sollte ein Integer-Literal kein Objekt sein, aber ein String-Literal? Das finde ich sehr inkonsistent.

Oder bastel doch mal ein foreach. Es wird niemals genau so geil sein wie

foreach( int myInt in myIntList )
    sum += myInt;

Und mit foreach ist es das selbe wie mit String. Jeder bastelt sich sein eigenes...

Ich kenne C# nicht genug, um zu wissen wie dort foreach gehandhabt wird. Aber was muss ich machen, damit meine Klasse auch in foreach benutzt werden kann?

Du musst ein Interface implementieren und einen passenden Enumerator schreiben. In C# 2.0 gibt es ein Sprachmittel für Enumeratoren, so dass man diese Klasse nicht mehr selber definieren muss:

public class Stack<T> : IEnumerable<T> {
        public IEnumerator<T> GetEnumerator()
        {
            for (int i = top; --i >= 0; )
            {
                yield return values[i];
            }
        }

        // Dass man dies braucht ist ein Design-Fehler aus alten Tagen  :-(
        IEnumerator IEnumerable.GetEnumerator()
        {
            return GetEnumerator();
        }
}

Da verbindet man dann wieder die Sprache zu sehr mit irgend welchen Interfaces und Methoden.

... und würde die Sprache verkomplizieren.

Nein, die Grammatik der Sprache wäre gleich kompliziert und der Umgang mit der Sprache wäre ganz erheblich einfacher.

Ich habe ja auch nie behauptet, dass die Gramatik der Sprache wesentlich schwieriger wird.

Ok. Was meinst du, würde komplizierter werden?

Die Sprache an sich, weil ich nun Klassen habe, die fest verdrahtet sind, von denen ich auf besondere Weise Objekte erzeugen kann etc.

[Clw]

TactX schrieb:

Was mir an D gefällt sind die Bezeichner für die einzelnen Datentypen. Kein unsigned long long sondern einfach nur ulong. Wobei ich die Bezeichner aus stdint.h (uint64_t) trotzdem besser finde.

Die gibts auch in D in der Standardlibrary:
http://www.digitalmars.com/d/phobos/std_stdint.html

Optimizer schrieb:

Function Templates  	Yes  	No  	Yes  	No  	Yes

Ich möchte jetzt mal nicht auf den Begriff Template rumreiten. Versteht jemand, was die Seite genau damit meint, was Java haben soll und C# nicht?

Zugegeben, die Seite ist ein wenig reißerisch, aber im Kern sind die Aussagen bezüglich D wahr.

Zeus schrieb:

Naja bei den Vergleich scheind DM mit Falschinformation zu glänzen.
In C++ kann ne Klasse ein Referenttype oder Werttype sein, oder?

Klassen sind in C++ immer Werttypen, soweit ich weiß. In D sind Klassen immer Referenztypen, mit allen Folgen, es ist aber trotzdem möglich Klassen auf dem Stack zu erstellen, diese haben dann aber einige Einschränkungen, bieten aber die Sicherheit, dass der Destruktor aufgerufen wird.

[Phoemuex]

rüdiger schrieb:

Ich denke, dass es universelle Programmiersprachen gibt, die alles gut können. C++ gehört da aber nicht zu.

Welche denn? Assembler? Java? LISP? Prolog?

Funktional, logisch, Objektorientiert?

[Zeus]

Clw schrieb:

Zeus schrieb:

Naja bei den Vergleich scheind DM mit Falschinformation zu glänzen.
In C++ kann ne Klasse ein Referenttype oder Werttype sein, oder?

Klassen sind in C++ immer Werttypen, soweit ich weiß. In D sind Klassen immer Referenztypen, mit allen Folgen, es ist aber trotzdem möglich Klassen auf dem Stack zu erstellen, diese haben dann aber einige Einschränkungen, bieten aber die Sicherheit, dass der Destruktor aufgerufen wird.

Wertetypen liegen auf dem Stack, Referenztypen auf dem Heap und in C++ hassu die Freiheit Objekte auf den Stack oder auf dem Heap zu erzeugen. Wenn ich falsch liege, sagt es mir.
Jep Scope Classen heisst das.

[Knuddlbaer]

Ich weiß nicht so recht was die Diskussionen sollen.

Niemand wird seine angefangene Projekte in D neu Implementieren weil die Sprache D nach (glaubt man Heise.de) 7 Jahren in der Version 1 vorliegt.
(Changelog lässt sich derzeit nicht gescheit einsehen, erster Eintrag vom Okt 2002)

Wenn ich mir dann die Vergleiche hier ansehe:
http://www.digitalmars.com/d/htomodule.html

fühle ich mich schon veralbert.

Besonders die vergleiche mit
__declspec(dllimport) int __stdcall foo(int a);
export extern (Windows) int foo(int a);

stören mich da, __declspec etc. hat nun mal nichts mit der Sprache C zu tun.

Einige der Vergleiche dürften sich, hätte man C++ angesetzt, erledigt haben.

Wenn wir aber schon teils auf Compilerspezifische bzw. OS spezifische Dinge zum hervorheben von D verwenden, dann hätte ich gerne D mit C++/CLI im vergleich oder C++ mit boost.

(Ah mist, die Seiten gehen kaum von D gerade, schlechte Basis für mich

Mir werden dann Delegates geboten,
es steht ein GC zur Vergügung,
es gibt typof
für interne Typen wie z.B. int kann ich einfach ToString aufrufen
mir stehen Properties zur Verfügung
static con und destruktor
etc.

Insgesammt sehe ich nur eine Menge Werbung, Sachen die schöner gelöst sind, sachen die schlechter gelöst sind. Aber nichts, was mir meine Arbeit auf anhieb deutlich einfacher machen würde oder die eingesetzten Werkzeuge mit einem Schlag ersetzen könnte.

Im Moment müsste ich auch sehr umdenken:

Templates cannot be used to add non-static members or functions to classes. For example: 

class Foo
{
    template TBar(T)
    {
	T xx;			// Error
	int func(T) { ... }	// Error

	static T yy;				// Ok
	static int func(T t, int y) { ... } 	// Ok
    }
}

Auch schaut

alias TFoo!(char, int, int) foo4; // instantiates #4

für mich nicht nach Template aus sondern nach Funktion irgendwas.

Bei

struct TFoo(int x) { }
static assert(is(TFoo!(3) == TFoo!(2 + 1)));   // 3 and 2+1 are both 3 of type int
static assert(!is(TFoo!(3) == TFoo!(3u)));     // 3u and 3 are different types

muss ich schon aufmerksam lesen, das mir das ! nicht verloren geht und aus dem Template nicht ein Funktionsaufruf wird.

Insgesammt sehe ich D mit interesse entgegen, aber ich sehe nichts ausschlaggebendes, was massig Leute von C++ zu D wandern lässt.

Für jede Sprache gibt es sinvolle Anwendungen, ich sehe hier aber kein Potential
andere Sprachen zu verdrängen. Die anderen Sprachen schlafen auch nicht und das Geld in der Marktwirtshaft wird auch nicht mit dem reinen Sprachumfang bzw. reinen Standard gemacht.

Ich finde den Hype verfrüht und die Diskussion C (C++) vs D genauso sinnfrei wie SpracheX vs SpracheY.

Lassen wir D doch einfach mal eine Zeit "wirken" und schauen mal was die Praxis zu D sagt. Da wird sich die Vorfreude sicherlich etwas gelegt haben und ein paar Ansichten anderst sein.