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