Re: [boost] [result_of] Allow result_of to work with C++11 lambdas

Subject: Re: [boost] [result_of] Allow result_of to work with C++11 lambdas
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2013-04-10 13:27:15

On 10/04/13 19:12, Nathan Crookston wrote:
> Hi Vicente,
>
> Vicente J. Botet Escriba wrote:
>
>> The problem is that result_of for compatibility problems is not able to
>> choose the version of result_of that works the better. So the user needs to
>> define one of these macros to select the best adapted to his needs. But a
>> Boost library needs to be portable and needs a result_of that works the
>> best depending on the compiler and the context used. Maybe we need another
>> result_of that has no backward compatibility issues.
>>
>
> If I'm understanding correctly, you're suggesting that compatibility
> problems are the reason result_of doesn't use the decltype-based
> implementation.  If so, I don't think it's quite true.  The reason why
> decltype isn't used for more compilers is that deduction fails in some
> cases where incomplete types are involved[1].  This isn't so much a
> backwards-compatibility issue since we'd like result_of to work in such
> cases, even today.

There are indeed compatibility problems to using decltype *instead of 
the result_of protocol*.
This is not what's proposed here though, it's proposed that decltype be 
used *if the type does not follow the result_of protocol*.

The proposed change is fully backwards-compatible.

I personally have my own implementation of result_of which does this. My 
implementation is also simpler, compiles faster, is optionally optimized 
for compilers with variadic templates (also supports compilers with 
decltype but no variadic templates), has preprocessing support, and has 
the added benefit that result_of<Sig>::type is only defined if Sig is 
callable.