On 11/29/2012 9:29 AM, Nathan Crookston wrote:
> Eric Niebler wrote:
>> Here's the surprising part:
>>
>> Jeffrey Lee Hellrung, Jr. wrote:
>>> - If F::result_type exists, return F::result_type;
>>> - Else:
>>> - If BOOST_NO_CXX11_DECLTYPE, return F::result< F ( Args... ) >
>>> - Else, if F::result<> exists, return F::result< F ( Args... ) >
>>> - Else return decltype( declval<F>() ( declval< Args >()... ) )
>>
>> The way I read this is that F::result_type (and F::result<>) is
>> taking precedence over decltype. AFAICT, you're suggesting that
>> result_of *not* compute the actual return type of a function
>> object, but rather return the declared result type, even if it's
>> wrong.
>>
>> In moving to a decltype-based result_of, we discovered just how
>> many function objects in boost were lying about their return types
>> via the TR1 result_of protocol. Now that we have decltype, we can
>> get the right answer always. I would be *immensely* surprised if
>> result_of ever got the wrong answer on a compiler that had
>> decltype.
>
> I understood the suggestion to apply when compilers had pre-3276
> decltype -- so the above wouldn't apply to latest clang, nor to
> other compilers once they support incomplete types.

Ah. Forgive me for having misunderstood the suggestion.

>> And btw, I don't think lambdas are required to have a nested
>> result_type typedef, are they? So what benefit does changing the
>> protocol have? Wouldn't you still need a wrapper anyway?
>
> No, they're not required.  That's the heart of the issue -- if
> result_of were modified (only for lacking compilers) to fall back to
> decltype, then the lack of result_type wouldn't require special
> handling by the user.

That's an interesting suggestion. (Thinking ...) It requires the ability
to detect the presence or absence of a nested result<> struct template.

IIRC, this is difficult, and doesn't work on all compilers.

But I could
be mistaken.

Would you be willing to open a trac ticket and attach a patch?