According to my understanding, this happens when you emit more than 64k functions. The compiler really should enable /bigobj by default (or at least automagically) but for historical reasons it doesn't.
I certainly can see that a C++11 standard library when combined with Boost might just exceed that limit regularly. I might add that seeing as VS2012 doesn't output binaries which will execute on pre-Vista, it might be worth turning /bigobj on by default in VS2015 and needing a /-bigobj to get the VS2005 behaviour.
I also think you haven't looked at the bug closely enough - I'm *not* calling result_of<> in the way you think.
Hmm. VC rejects this code:
C:\Temp>type purr.cpp template <typename T> struct NoCharsAllowed { static_assert(sizeof(T) > 1, "No chars allowed!"); };
template <typename A> void purr(int, const A&);
template
typename NoCharsAllowed<B>::type purr(void *, const B&, Types...); int main() { purr(1729, 'x'); }
C:\Temp>cl /EHsc /nologo /W4 /c purr.cpp purr.cpp purr.cpp(2) : error C2338: No chars allowed! purr.cpp(10) : see reference to class template instantiation 'NoCharsAllowed<char>' being compiled
However, GCC accepts it, contrary to my understanding of the Standard. My brain tells me that template argument deduction should run for the B overload even though it will ultimately be nonviable (because 1729 isn't convertible to void *). It also tells me that if it runs, the static_assert should really explode and not trigger SFINAE. Either GCC is wrong, or one of these parts of my mental model is wrong. I'll ask our compiler team.
Thanks for the example. It helped me see your position a lot. In my head as a non-compiler implementer, as return types have no effect on overload resolution I wouldn't waste compiler time compiling them until I know I have selected the overload as the one it's going to be. If the standard says we should do other than that, I think that's a very good candidate for a defect report as we gain little while losing much by compiling the return type during the overload resolution stage (except as a method to silently rule out that overload, but that's not how C++ has done things till now). I also think that given the trend we're seeing in post-C++11 towards a less cookie cutter template syntax like the forthcoming auto lambdas (and one would assume auto functions are coming), return types need to get less in the way anyway. BTW, in your later post you mention clang won't compile the above. As clang does compile my call() test case, I take it that result_of<> in libstdc++ and libcxx are the SFINAE friendly variants you mentioned? If so then arse, because for VS2013 I'm going to have to make a special exception just for that compiler version alone to use boost::result_of<>. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.