On 3/20/07, Eric Niebler <eric@boost-consulting.com> wrote:
Daniel Walker wrote:
On 3/20/07, Eric Niebler <eric@boost-consulting.com> wrote:
Daniel Walker wrote:
Still, for compilers that Boost.Typeof doesn't support, it would be nice if result_of could handle Boost.Lambda at least. More recent libraries and future libraries could consider adopting a previously existing practice (result<F(Args) or sig<tuple<Args> >) that result_of can support without typeof.
IMO, you have this backwards. Rather than patch result_of to handle lambda, lambda function objects should be modified to follow the result_of convention. It's now standard, after all.
Good point. I considered doing that, but didn't want to intrude on any user code out there that follows the current Boost.Lamda convention. Of course, I don't mind submitting a patch to Boost.Lambda as you suggest if there's interest. That would help alleviate the problem of having multiple return type conventions among Boost libraries. I could also try to patch Fusion. Perhaps, my result_of patch could still be useful for providing backwards compatibility for current Boost.Lambda style user defined functors.
If lambda functors had both sig<> and result<> nested templates, then it would Just Work without causing any back-compat problems.
That's true, but I was concerned about funtors defined by lambda users. Currently, if a user wants to write a functor to be used in a lambda expression, the user needs to supply a sig<> to tell lambda what the functor's return type is. Of course, 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. And it's not too imposing to demand that they modify their functors to conform to the result_of standard, so long as they can still be used in lambda expressions. I think I'll try to patch lambda. Thanks! Daniel