From: Doug Gregor (dgregor_at_[hidden])
Date: 2007-01-08 15:13:21
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