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: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2013-04-11 22:00:46

On Apr 10, 2013, at 2:09 PM, Vicente J. Botet Escriba <vicente.botet_at_[hidden]> wrote:

> Le 10/04/13 19:39, Nathan Crookston a écrit :
>> Hi Vicente,
>> 
>> Vicente J. Botet Escriba wrote:
>> 
>>> Le 10/04/13 19:12, Nathan Crookston a écrit :
>>> 
>>> 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.
>>>> 
>>>>  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?
>>> 
>> I think it would be uncommon for the user to define those macros.  Here's a
>> situation where it may be useful:
>> 
>> I have a library which I claim supports VC9 and Clang.  I do my development
>> with clang 3.2, and rely on some form of automated testing to verify it
>> works with MSVC.  I may commonly forget to add result_type or a nested
>> struct to my functors, since clang uses decltype.  After the Nth time, I
>> may, during my own development, #define BOOST_RESULT_OF_USE_TR1, just so
>> that I'm not continually breaking the VC9 build.
>> 
>> So again, I think it's uncommon.
> Do you mean that if a library author develops and tests with both compilers an even more at once he would need to define BOOST_RESULT_OF_USE_TR1 from the beginning even if defining BOOST_RESULT_OF_USE_DECTYPE works better on some compilers? But the library author cannot know how the users would define their Functors so it can not define these macros.
> 
> I think that I need to re-read the result_of documentation to understand correctly what is proposed.

I had thought of this proposal as a third configuration. So, our established migration path from using TR1 by default to using decltype by default would remain, but we would add a third option: a hybrid that could switch between TR1 mode and decltype mode smartly.

- Daniel