On Jan 8, 2007, at 1:19 PM, Tobias Schwinger wrote:
Doug Gregor wrote: [snipped] It doesn't really take that esoteric of a case to be useful, though. Let's consider a variadic function wrapper and a call that doesn't fit the arity of the wrapped object:
Now, with "SFIANE propagation" we get "no match for call to <wrapper>..." reported in client code - without "SFINAE propagation" we get "no match for call to <wrapped>...", reported in the gory details of the wrapper and (possibly lots of) trace diagnostics burying it.
Right. The esoteric case came to mind first... I think that says something about my mental state :)
Now, in C++0x, the metaprogramming-based implementation and specification of result_of is going to disappear in favor of decltype.
We can remove that nested result class template, then...
Right! But we don't get SFINAE-like behavior.
With a decltype-based implementation, the code above would be ill-formed, so I think the right answer is "do the same thing that the decltype implementation would do."
... but I guess we might be able to use that very language extension to detect whether a function object has a call operator that suits given argument types.
This has gone back-and-forth many times. At present, the expression inside decltype won't have SFINAE capabilities, just like sizeof doesn't work with SFINAE now.
Further, a client may still define a specialization for std::result_of to control whatever is in there.
That's actually undefined behavior; at least, if the client specializes std::result_of to return something other than the actual return type, she invokes undefined behavior.
Not trying to convince you - just thinking aloud...
I'd like to have SFINAE behavior if we can get it, but we really did have decltype in mind when we wrote result_of, and we shouldn't promise more than what decltype can deliver (even if we can get it with today's "result_of", which is broken in many other ways). Cheers, Doug