I'd also like to know *why* this works, and indeed if it's guaranteed to. In particular, is it guaranteed that the virtual what() member of the sfinae_error class is instantiated at the outermost call site and not elsewhere (thereby eliminating the deep template back-trace)? I really just stumbled on this technique by accident, and I don't know how thin the ice is here. Both clang-trunk and gcc-4.7 think it's ok.
I'll wager an explanation... maybe somebody will be able to refine it. Because what() is virtual, it needs to build the vtable for sfinae_error. However, because what() isn't actually used in the program, it is instantiated at the very end of translation. Basically, the point of instantiation is at the top-level, at the end of the translation unit. There's no template instantiation stack to unwind. Comment out the "virtual" keyword in front of what(). The program should actually compile. The try_call doesn't actually force a compilation error, it suppresses it. This only works because sfinae_error happens to be polymorphic. Using unused virtual functions to defer instantiation traps is incredibly clever... If my understanding is correct :)
IMO, this is now approaching something of real value. My personal experience using this with Proto-11 is that it dramatically improves error messages. I can also easily imagine how this can be used to implement a very nice concept-checking library for C++11 that approximates auto-concepts. Andrew, any thoughts on this? You've done far more work in this space than I have.
I want to say yes, but I'm not sure. What's really needed is a combination of this and static_assert. I want compilation to stop *and* I want brief errors. Hmm... Let me get back to you on this.