Hello.

I hope I've come to a right forum to have answered my questions. :-)

A few days ago I began to be interested in the upcoming C++0x standard. And I was surprised by some of the committee’s decisions. I'd like to know if there's a place to learn the reasoning behind these decisions - why the committee chose such awkward solutions in some cases instead of going in a more straightforward way. I'm not saying the committee decided wrongly, I'd just like to learn their rationales. In particular:

- Template aliases
Why the committee decided to change syntax to
Code:
template<typename T>
using TypeName = SomeType<3,T>
instead of extending the current typedef
Code:
template<typename T>
typedef SomeType<3,T> TypeName
?
Using different syntax for essentially the same thing complicates the language, especially when semantics of the "using" keyword differs from the semantics of "using" declarations.

- Attributes
Why was chosen the "postfix" notation (i.e. attributes are specified after function, parameter etc. names) instead of the "prefix" notation like in C#. IMO the prefix notation is more readable.
Moreover, one would expect that attributes do not change the semantics of the source code, they should be rather "hints". But some of the proposed attributes do not seem to satisfy this criterion.

- Lambdas
Why the lambda syntax is so cryptic and does not resemble the more straightforward syntax of anonymous functions in other C-like languages? Perhaps inspiration by Haskel?

- Garbage collector
Why there are attempts to introduce the garbage collector at the language level instead of at the library level? When defined at the library level, the garbage collector could already have been part of the standard instead of postponing it repeatedly to later specs. I don't believe that the GC at the language level can be introduced transparently, without breaking the current code. The GC at the library level should work in cooperation with smart pointers (allocated memory would be available for garbage collection if no shared_ptr was pointing to it), like it does in most of the already existing GC implementations.
IMO, the only thing that GC at the library level now needs to specify are the finalizers - the spec must standardize their syntax (perhaps the Microsoft's syntax from managed C++?) and their relation to destructors (e.g. destructors would call the finalizers implicitly, when they are both defined).
(Concerning the ever-occurring question of managing scarce resources, the unique_ptr might be determined for this task, for instance.)

- shared_ptr
This question is related to the previous one: Why is shared_ptr restricted to reference counting implementation? From the point of view of shared_ptr users, the exact garbage collection mechanism is irrelevant. But if shared_ptr is adopted to the standard in the current form, relaxing its implementation from reference counting to other GC mechanisms would be very difficult in the later specs.

- etc.

I drew my information especially from:
http://www2.research.att.com/~bs/C++0xFAQ.html (Bjarne Stroustrup notes)
http://en.wikipedia.org/wiki/C%2B%2B0x (Wikipedia overview of C++Ox)
http://www.informit.com/guides/content.aspx?g=cplusplus (Danny Kalev notes)
http://open-std.org/JTC1/SC22/WG21/d...2009/n3000.pdf (current C++0x draft)

Thank you,
Martin.