On 3/20/07, Eric Niebler <eric@boost-consulting.com> wrote:
Giovanni Piero Deretta wrote:
What about doing both? Result_of would implement (maybe undocumented and deprecated) sig support. Lambda would implement and document both result and sig, deprecating the latter. In a release or two, both lambda and result_of would drop sig support. The users should have plenty of time for updating their code.
I'm not sure this is a good idea. I haven't looked at the patch to mpl's has_xxx code to make it detected nested class templates, but I wonder how portable it is to older compilers. I know from experience how finicky the result_of implementation is, and getting this to work on all the compilers result_of currently works on would be a difficult (impossible?) task. I'm willing to be proved wrong, however.
You're right that detecting nested templates may not be portable to older compilers. However, my result_of patch doesn't require full nested template detection support. My patch for has_template_xxx (I didn't try to change has_xxx to support both nested classes and template classes) provides functionality on unsupported compilers the same way has_xxx does. has_template_xxx::value is always false on unsupported compilers (or a user supplied default). In my patch for result_of, lack of support for has_template_xxx is handled by checking BOOST_MPL_CFG_NO_HAS_TEMPLATE_XXX. In this case, partial specializations for lambda::lambda_functor are provided so that lambda expressions can be supported, even though user defined functors using sig<> cannot. result_of already requires that the compiler support partial specialization. So, to the best of my knowledge, this doesn't add an additional limitation on the number of compilers result_of can work on. Daniel