On 3/22/07, shunsuke <pstade.mb@gmail.com> wrote:
Daniel Walker wrote:
Plus, as Eric pointed out earlier in this thread, the result_of convention of using result<> for return types is now standard (is that TR1?). Why shouldn't lambda follow it?
As pointed, lambda should and can follow 'result_of' by using this way: http://tinyurl.com/2xw4s2 , which will be <boost/lambda/result_of.hpp> or something. Note that the nullary instantiation seems not special case.
OK I think we're getting closer to a good solution. Your file has specializations for lambda::lambda_functor that work for lambda expressions, which is why the nullary instantiations work. My result_of patch also had a specialization for lambda::lambda_functor, which made the nullary case work. If lambda expressions provided the standard result<> (as Eric suggested and my lambda patch implements) only the specializations for the nullary case would be necessary (unless this special case were removed entirely from result_of using has_template_xxx). I would be perfectly happy using your <boost/lambda/result_of.hpp> for the nullary case alone, if we moved it to <boost/lambda/detail/result_of.hpp> and had the boost/lambda/* headers include it so that lambda/result_of interoperability was transparent to the user. That combined with the lambda patch would probably suffice. However, this doesn't take care of the case where the user would like to use a lambda compatible functor with result_of directly, as in calling a functor right away rather than delaying the call with lambda::bind per my previous example in this thread. It also doesn't take care of your example of calling lambda::construct<> directly without lambda::bind. To handle lambda::construct<> and the other lambda wrapper functors you could add nullary specialization of result_of to your file. We should also have the wrapper classes expose result<> so that they are more standard conformant. This will handle the nary result_of cases for lambda wrapper functors. To handle arbitrary user defined lambda compatible functors still requires adding sig<> support to result_of (or a function adapter that user's can use to convert their functors). Or we could just not handle this case. Users currently can't use these functors with result_of anyway. So, I suppose no one's feelings will be hurt if result_of doesn't support their current lambda compatible functors. Besides, when they upgrade to the result<> standard that lambda accepts with my patch, they get result_of compatibility as a bonus. If we don't handle user defined lambda compatible functors I see no need to patch result_of at all, which I think would make everyone happy. This is beginning to sound like a good approach to me.
The third case could be changed to be dependent on the number of arguments (after giving the user a chance to supply result_type or result<>) if that's preferable. This is simple to implement with has_template_xxx. Am I missing something?
As the rationale states, nullary intantiations of 'result_of' must always succeed even if the functions are never called. (Hence, it has the *default* result type -- 'void'.) Can has_template_xxx detect whether or not a sig-compatible functor is nullary-callable?
Yes. With my patch nullary instantiations of result_of are succeeding: result_of<F()>::type is void. The problem as far as I can tell is that result_of is choosing the default void rather than correctly deducing the actual return type as given by F::result<F()>::type or F::sig<tuple<F> >::type. But this has always been a limitation of result_of. The way to get around it is by specializing result_of for nullary F. I believe has_template_xxx could take away this limitation by only choosing the default type void when the functor doesn't have F::result<F()>.
I guess a sig-compatible functor which is nullary-callable must be ported to result_of, even if the patch is applied.
The same is true for a result-compatible functor as described above. This is an existing limitation of result_of which we may or may not want to address.
If user workarounds of sig-compatible functor users cannot be removed, that patch loses the original intention?
I'm not sure if I fully understand your question, but the patch doesn't lose the original intent entirely. Users can still use nary sig-compatible functors, which they couldn't use before. (However, as I stated above, it would be convenient but I'm not sure that it's necessary for result_of to support the current sig convention.) Lambda users are in the same boat as people writing result-compatible functors when it comes to nullary calls. They need to write a specialization of result_of for when their functor is called with no arguments. result_of doesn't attempt to automatically deduce the type, although it could with has_template_xxx.
has_template_xxx seems not to work. I tried this:
typedef char value_type; BOOST_MPL_ASSERT(( has_template_result< pair_maker, pair_maker(value_type, value_type) > ));
This assertion fails under VC7.1/VC8.
That's expected. Someone needs to cover the compiler workarounds that has_xxx includes, and I'm not sure if I can do that right away. I may give it a shot. Note that result_of still works on VC7.1 and VC8, but the new functionality is not be available. Daniel