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.