g++ rejects, clang++ accepts: foo(x)("bar")("baz"); - c++

Question

Somebody had asked the other day why something compiles with clang, but not with gcc. I intuitively understood what was happening and was able to help the person, but it got me wondering -- according to the standard, which compiler was correct? Here is a boiled down version of the code:
#include <iostream>
#include <string>
class foo
{
public:
foo(const std::string& x):
name(x)
{ }
foo& operator()(const std::string& x)
{
std::cout << name << ": " << x << std::endl;
return (*this);
}
std::string name;
};
int main()
{
std::string x = "foo";
foo(x)("bar")("baz");
return 0;
}
This compiles fine with clang++, but g++ gives the following error:
runme.cpp: In function ‘int main()’:
runme.cpp:21:11: error: conflicting declaration ‘foo x’
foo(x)("bar")("baz");
^
runme.cpp:20:17: error: ‘x’ has a previous declaration as ‘std::string x’
std::string x = "foo";
If I add a pair of parentheses in line 21, g++ is happy:
(foo(x))("bar")("baz");
In other words, g++ interprets this line as:
foo x ("bar")("baz");
Methinks itsa bug in g++, but again, I wanted to ask the standard experts, which compiler got it wrong?
PS: gcc-4.8.3, clang-3.5.1

Answer 1

As far as I can tell this is covered in the draft C++ standard section 6.8 Ambiguity resolution which says that there can be an ambiguity between expression statements and declarations and says:
There is an ambiguity in the grammar involving expression-statements
and declarations: An expression statement with a function-style
explicit type conversion (5.2.3) as its leftmost subexpression can be
indistinguishable from a declaration where the first declarator starts
with a (. In those cases the statement is a declaration. [ Note: To
disambiguate, the whole statement might have to be examined to
determine if it is an expression-statement or a declaration. This
disambiguates many examples. [ Example: assuming T is a
simple-type-specifier (7.1.6),
and gives the following examples:
T(a)->m = 7; // expression-statement
T(a)++; // expression-statement
T(a,5)<<c; // expression-statement
T(*d)(int); // declaration
T(e)[5]; // declaration
T(f) = { 1, 2 }; // declaration
T(*g)(double(3)); // declaration
and then says:
The remaining cases are declarations. [ Example:
class T {
// ...
public:
T();
T(int);
T(int, int);
};
T(a); // declaration
T(*b)(); // declaration
T(c)=7; // declaration
T(d),e,f=3; // declaration
extern int h;
T(g)(h,2); // declaration
—end example ] —end note ]
It seems like this case falls into the declaration examples in particular the last example seems to make the case in the OP, so gcc would be correct then.
Relevant section mentioned above 5.2.3 Explicit type conversion (functional notation) says:
[...] If the type specified is a class type, the class type shall be complete. If the expression
list specifies more than a single value, the type shall be a class with a suitably declared constructor (8.5, 12.1),
and the expression T(x1, x2, ...) is equivalent in effect to the declaration T t(x1, x2, ...); for some
invented temporary variable t, with the result being the value of t as a prvalue.
and 8.3 Meaning of declarators which says:
In a declaration T D where D has the form
( D1 )
the type of the contained declarator-id is the same as that of the
contained declarator-id in the declaration
T D1
Parentheses do not alter the type of the embedded declarator-id, but
they can alter the binding of complex declarators.
Update
I was originally using N337 but if we look at N4296 section 6.8 was updated an it now includes the following note:
If the statement cannot syntactically be a declaration, there is no ambiguity, so this rule does not
apply.
which means that gcc is incorrect since:
foo x ("bar")("baz");
can not be a valid declaration, I originally interpreted paragraph 2 as saying if you case begins with any of the following then it is declaration, which is perhaps how the gcc implementor interpreted as well.
I should have been more suspicious of paragraph 2 since the only normative part of paragraph 2 really said nothing with respect to paragraph 1 and seems to place a requirement on an example which is not normative. We can see that that statement form paragraph 2 is now actually a note which makes much more sense.
As T.C. noted below, paragraph 2 was actually never normative, it just appeared that way and he linked to the change that fixed it.

Answer 2

If we remove the line
std::string x = "foo";
then g++ complains about:
foo(x)("bar")("baz");
with the syntax error:
foo.cc:20:18: error: expected ',' or ';' before '(' token
foo(x)("bar")("baz");
I do not see how foo (x)("bar")("baz"); could be a valid declaration, and apparently g++ can't either. The line foo x("bar")("baz"); is rejected with the same error.
The "ambiguity resolution" mentioned in Shafik's post only kicks in when the expression-statement is syntactically indistinguishable from a declaration. However in this case it is not a valid declaration syntax so there is no ambiguity, it must be an expression-statement.
g++ fails to process the line as an expression-statement so it is a g++ bug.
This is eerily similar to this g++ bug recently discussed on SO; it seems that g++ is perhaps deciding too soon in processing that the line must be a declaration .