Actually, the whole rant is largely just a rant, quite clueless and poorly argued in places (e.g. nullptr vs NULL). However, it's hard not to agree that auto function and lambda syntax (the -> and [] things) and rvalue references are astonishingly bad additions. It's obvious that Boost people have very strong influence on a committee, because hardly anyone else outside of Boost needs these features.

  for (std::vector<int>::const_iterator i = vec.begin(); i != vec.end(); ++i)

  for (auto i = vec.begin(); i != vec.end(); ++i)

Rvalue references solve a problem that library writers who are concerned with performance have. That most programmers don't need rvalue references misses the point - most programmers will probably depend on a library that benefits from rvalue references.

  auto func(int x) -> double;

  auto func(int x) -> decltype(x);

  decltype(x) func(int x);

  decltype(x) func(int x);

I actually agree that typeof is more natural, and I would prefer that keyword. But one of the committee's goals is to not have new language feature names clash with old conventions. Hence, the hashtable-based associative containers will be called unordered_, and not hash_.

Duh, noooo, really ? Have you ever wondered what magic causes this snippet to compile:

  struct foo
  {
    foo() { bar = 1; }
    int bar;
  };

I'm guessing that the real reason why they ended up with this ass-backward syntax was to try and achieve some consistency between these two cases:

  auto <variable>;
  auto <function>;

This isn't slashdot. Please be civil.

Read Section 5 for the rationale provided by the committee members who proposed the syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n170...

In particular, the name collision problem does not happen with classes because each class is a new scope.

Take it easy. You don't appear to have a good understanding of the compiler guts. What you said above was quite clueless, hence the reaction.

Also, slashdot as a metric of incivility - that's bold :)

> Read Section 5 for the rationale ..

I read the whole thing before I first posted in this thread. Since they are extending function declarations with a new construct, nothing precludes them from creating a scope for it. In other words, declspec() arguments should have a scope of a function declaration they appear in. Their claims that this also complicates parsing is just a speculation, and not too convincing one.

Introducing a new scope would, I think, introduce more corner cases than the ugliness of the new syntax. (And I do agree that it's ugly in the context of C++ which already has a function syntax.) Right now, scopes are only introduced inside namespaces, classes/structs, functions, and explicit braces. Having a new scope start before a function and its parameters are declared is counter-intuitive to me.

Now, I might actually be willing to take counter-intuitive semantics to avoid the syntactic ugliness, but that's not my point. The point I've been trying to make is that the committee has considered these issues; they didn't blindly make a bunch of decrees.

Your first response rebutted the point that I didn't make. Your second response was stating trivial stuff that was obvious to the point of not being even worth mentioning. So, yeah, I was also trying to have a discussion and go over finer points of the alternatives and why they used the least attractive one, but it didn't quite work.

> Right now, scopes are only introduced inside namespaces, classes/structs, functions, and explicit braces.

You forgot for loops. Their scoping is virtually identical to a function declaration scope if latter were to be used.

> The point I've been trying to make is that the committee has considered these issues; they didn't blindly make a bunch of decrees.

You have to realize that not all decisions made by the committee are based on a technical merit. There is quite a bit of politics and ego involved. Whatever they converge on might be a result that everyone is equally unhappy with rather than the opposite. Taking their decisions as written in stone makes very little sense .. unless, of course, they come directly from Bjarne :)

A well-known anecdote is a history of standardizing IPsec suite of protocols - a showcase for ego clashing. It took over two years to converge to something that the majority of a workgroup agreed with. It was a compromise on top of a compromise and the result was one of the most ambiguous and awkwardly written set of RFCs.

I'm not sure if the author knows this, but the fact that nullptr is even needed is a design flaw of C++. That is,

    int foo = NULL;