Kurz und Knapp, meine Idee wäre folgende gewesen:

//statt
template<class T>
using Vec = std::vector<T,My_alloc<T>>;

// mit typedef
template<class T>
typedef std::vector<T,My_alloc<T>> Vec;

Natürlich bin ich mir aber sicher, dass die Leute des Kommitees darauf auch gekommen sind, die Idee aber wegen ewaiger Ungereimtheiten verworfen haben.
Genau diese Ungereimtheiten interessieren mich. Ich übersehe da sicher irgendwelche Spezialfälle, bei denen diese Syntax nicht funktioniert, es wäre nett, wenn ihr mir genau diese nahelegen könntet.

using foo = double;

geht jetzt auch. Hurrah, Konsistenz!

Man kann auch sofort sehen, was da passiert:
neuer_name = typ
(bei komplizierteren Beispielen merkt man dann den Vorteil)

typedef int*(*bar)(int);
// oder
using bar = int*(*)(int);

Genaue Gründe kenne ich auch nicht.

Hurrah, Konsistenz!

och schrieb:

(bei komplizierteren Beispielen merkt man dann den Vorteil)

och schrieb:

Genaue Gründe kenne ich auch nicht.

Ich kann zur Not damit leben, nicht zu erfahren, warum nicht.

ich find's gar nicht übel, dass using typedef komplett ersetzen kann jetzt:

using foo = double;

geht jetzt auch. Hurrah, Konsistenz!

Für diverse Sprachmittel eine Alternativmöglichkeit einzuführen, obwohl die bisherigen ihren Dienst gut geleistet haben, ist nicht gerade der Inbegriff von Konsistenz. Ich glaube auch nicht, dass sich die Vision von einheitlichem Sprachmittelgebrauch durchsetzen wird. Dafür ist es in C++ zu spät. Ich befürchte eher, man könnte mit diesem Vorgehen das genaue Gegenteil erreichen, weil sich Codestile noch stärker unterscheiden werden.

Ich bin da grundsätzlich skeptisch. Konsistenz ist bestimmt nicht der richtige Ausdruck.

// Alles Initialisierungen für int mit Wert 5
int a(5);
int a{5};
int a = {5};
int a = 5;

std::complex<float> c(7); // Konstruktoraufruf mit einem Parameter
std::complex<float> c{7}; // Konstruktoraufruf mit einem Parameter
std::vector<float> v(7); // Konstruktoraufruf mit einem Parameter
std::vector<float> v{7}; // Initialisierungsliste mit einem Element 7

Soviel zur Einheitlichkeit. Funktionssyntax ist auch sowas (für Spezialfälle braucht man die neue Syntax, ja). An anderen Orten wird dafür krampfhaft recycelt und versucht, imaginäre Sprachzusammenhänge zu suggerieren.

MyClass() = default;
MyClass(const MyClass&) = delete;

enum class MyEnum {};

Furchtbar. Was diesen Teil von C++0x betrifft, bleibt mir nicht viel mehr als übrig. Zum Glück gibts Features, auf die man sich freuen kann.

MyClass() = default;
MyClass(const MyClass&) = delete;

enum class MyEnum {};

Ähh das Erste kannte ich...und hielt es irgendwie für sinnvoll.

Aber was soll bitteschön das zweite sein? //edit: bedeutet das: der copy-ctor ist nicht vorhanden?

Und das Dritte?

//edit
Ich glaube das Problem bei Typedef ist, dass Typedef einen Typen beschriebt. Ein Template-alias ist aber kein Typ. Es ist nur etwas, was irgendwann mal ein Typ werden könnte. Deswegen wäre Typedef inkonsistent.

http://www2.research.att.com/~bs/C++0xFAQ.html#enum

och schrieb:

ich find's gar nicht übel, dass using typedef komplett ersetzen kann jetzt:

using foo = double;

geht jetzt auch. Hurrah, Konsistenz!

Für diverse Sprachmittel eine Alternativmöglichkeit einzuführen, obwohl die bisherigen ihren Dienst gut geleistet haben, ist nicht gerade der Inbegriff von Konsistenz.

Nun, aus irgend einem technischen Grund gibt's kein templatisiertes typedef. Man hat daher diese using-Syntax benutzt. Mit Konsistenz meine ich, dass diese using-Syntax auch für "normale typedefs" herhalten kann.

Von dem initializer_list-Kram bin ich auch nicht gerade begeistert. Ich sehe da bis heute noch keine Verwendung für -- außer in kleinen (IMHO) praxisfernen Code-Beispielen wie

int main() {
  map<string,string> telefonbuch = {
    {"Oskar", "12345"},
    {"Wilhelm", "54321"}
  };
}

Sowas macht man halt nicht in "echten" PRogrammen, wo die Daten aus Dateien/Datenbanken/Internet/was weiß ich herkommen -- und nicht im Quellcode hardgecodet sind.

Ich muss aber auch gestehen, dass ich dieses initializer_list-Zeug noich nicht 100% verstanden habe. Ich raffe nicht, wo die Elemente gespeichert werden, wie lange die leben. Die initializer_lists scheinen auch nicht gut mit "move semantic" kombinierbar zu sein. Die Iteratoren liefern nämlich immer Referenzen auf const. Und dann werden die temporären Strings wie string("Oskar") und so, wohl kopiert, statt "gemovet". ... (?)

Aber was soll bitteschön das zweite sein? //edit: bedeutet das: der copy-ctor ist nicht vorhanden?

Ja. Also wie wenn man heute etwas privat und undefiniert macht, aber mit leicht besserer Compilerfehlermeldung.

otze schrieb:

Und das Dritte?

Neue enum s, die den umliegenden Scope nicht mehr überfluten. Mit class hat enum class rein gar nichts zu tun. enum struct wäre meiner Meinung nach um einiges besser gewesen, weil Struktur allgemeiner interpretierbar ist.

otze schrieb:

Ich glaube das Problem bei Typedef ist, dass Typedef einen Typen beschriebt. Ein Template-alias ist aber kein Typ. Es ist nur etwas, was irgendwann mal ein Typ werden könnte. Deswegen wäre Typedef inkonsistent.

Danke, das scheint mir ein plausibler Grund zu sein. Dann kann ich die Entscheidung schon ein wenig besser nachvollziehen...

Mit Konsistenz meine ich, dass diese using-Syntax auch für "normale typedefs" herhalten kann.

Ja, das hab ich schon so verstanden. Nur finde ich es etwas idealistisch, wenn davon ausgegangen wird, dass mehr syntaktische Möglichkeiten für ein und die selbe Semantik ausschliesslich zu einheitlicherem Code führen.

Ich meine, bisher war doch alles recht verständlich. Initialisierungsbeispiel: Man nimmt Type obj(args) im allgemeinen Fall, Type obj = arg; für kompatible Typen, Type obj = {args} für Aggregate. Ich sehe keinen Anlass, diese Dinge gleich zu behandeln und dafür eine neue Schreibweise einzuführen. Noch dazu eine, die zwar viele Fälle vereinheitlicht, jedoch neue Inkonsistenzen mit sich bringt (siehe std::vector -Beispiel).

och schrieb:

Von dem initializer_list-Kram bin ich auch nicht gerade begeistert. Ich sehe da bis heute noch keine Verwendung für -- außer in kleinen (IMHO) praxisfernen Code-Beispielen wie

Ich finde std::initializer_list ein sehr interessantes Feature, nur die Vermischung mit Konstruktoraufrufen bereitet mir etwas Sorgen. Beispielsweise existiert auch diese Form:

return MyClass(47, "hallo"); // C++98

return {47, "hallo"}; // C++0x

Sicher keine schlechte Idee, gerade im Bezug auf Typinferenz mit auto und decltype . Aber warum die geschweiften Klammern? Ich hätte sowas schön gefunden:

return auto(47, "hallo");

Zurück zu std::initializer_list : Solche hardcodierten Listen sind zwar wie du sagst selten anzutreffen, aber vielleicht ergeben sich plötzlich neue Anwendungsfälle. Ein spontaner Einfall:

// C++98
CallbackSystem sys(47);
sys.RegisterFunction(&Func1);
sys.RegisterFunction(&Func2);
sys.RegisterFunction(&Func3);

// C++0x
CallbackSystem sys(47, {&Func1, &Func2, &Func3})

Initialisierungslisten können ja nicht nur als Datentabellen benutzt werden. Gibt es nicht auch eine Verwendung in Zusammenhang mit Variadic Templates? Ich kenne mich diesbezüglich auch zu wenig aus...

Gut, das eigentlich schon alles, was ich wissen wollte (wenn noch jemand einen guten Grudn für using hat, dann aber trotzdem immer her damit^^), ich danke allen für die Antworten.