VS2012 RC gives the same error. Clang also compiles without error. Based on that I would say that VS is probably wrong, but I think it's a bit of a grey area whether the compiler should want the definition of a type when evaluating operators for which there is an explicit external operator defined, so I would personally err on the side of them being right.

edd, are you sure you're not including ostream or other library by mistake? That library would fix this error.

According to MSDN and cpp.reference.com and even gcc, iosfwd contains only forward declaration, making me believe you're the one who made mistake.

Sources:
http://msdn.microsoft.com/en-us/library/1af12yty%28v=vs.110%29.aspx
http://en.cppreference.com/w/cpp/header
http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.1/group__s27__2__iosfwd.html

According to MSDN and cpp.reference.com and even gcc, iosfwd contains only forward declaration, making me believe you're the one who made mistake.

That's true, but his code doesn't really use anything that requires the definition of the class, so a forward declaration is all that would be necessary for the compiler to evaluate the expressions.

You can replace that code with this:

struct foo { };

class mynonexistentostream;

mynonexistentostream &operator<< (mynonexistentostream& out, const foo &) { return out; }

void format(mynonexistentostream& out, const foo &x) { out << x; }

int main()
{
return 0;
}


and the result is the same; an error on VS and no error on the other compilers, with no headers being included at all.

A compiler needs to evaluate any class member operators and namespace-scoped operators to determine which one to use, but in this case the namespace-scoped operator is clearly the best possible option, so a compiler would be able to evaluate things without having the class definition. Whether a compiler is actually required to do so per the standard I'm not sure about. There's a very good chance that it's not, and both may be technically compliant.

Edit: nevermind, followup coming.

Actually after further investigation, it appears that Visual Studio is patently wrong. The reason for the error is not because of operator resolution issues, it's because of an apparent compiler limitation that does not allow references to undefined types to be returned from a function if they are not assigned. C2027 says that references to undefined types are not allowed, but that is not the case; if their example code is changed to the following it compiles fine:

A& a = CreateA();

It just doesn't work if the return value is unassigned as in their example.

Per section 5.2.2 of the C++ standard, the result type of a function call that returns an lvalue reference is an lvalue, so an incomplete type should be fine.

Since the operator << returns a reference, and it is not being assigned, the same error is being invoked.

A workaround for your code could then be this:

void format(std::ostream &out, const foo &x) { std::ostream& t = out << x; }

which should compile fine.

Update: so, apparently the reason that it doesn't work in VS is because VS is unable to convert an undefined type to type void, and a function with the return value unassigned is equivalent to casting to type void, i.e. (void)CreateA();

The C++ standard states that "Any expression can be explicitly converted to type cv void, in which case it becomes a discarded-value expression."

Therefore VS is wrong and the others are right.