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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-10 13:27:48

Le 10/04/13 19:12, Nathan Crookston a écrit :
> 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.
>
> I think individual boost libraries shouldn't need to worry about the
> macros.  Users may need to explicitly define one of the macros if they
> develop on a compiler which supports decltype-based result_of, but wish to
> support compilers without decltype.
>
> In short, I think that (with the decltype fallback) result_of *will* choose
> the best implementation, and (if the patch is applied) defining a macro to
> explicitly select a back end should be done for cross-platform
> compatibility reasons.
>
> Thanks,
> Nate
>
> [1] http://lists.boost.org/Archives/boost/2010/04/164714.php -- very
> instructive discussion
>
If you are right and after the patch result_of would provide the best we 
can do now, why the user would need to define any of these macros?

Vicente