From: Eric Niebler (eric_at_[hidden])
Date: 2007-03-20 13:47:45
Daniel Walker wrote:
> On 3/20/07, Eric Niebler <eric_at_[hidden]> 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.
-- Eric Niebler Boost Consulting www.boost-consulting.com