Re: [Boost-users] [Range & c++0x Lambdas] Can this be done?

Subject: Re: [Boost-users] [Range & c++0x Lambdas] Can this be done?
From: Nathan Crookston (nathan.crookston_at_[hidden])
Date: 2012-11-29 00:21:22

Jeffrey Lee Hellrung, Jr. wrote:

> Nathan Crookston wrote:
> [...]
>
> With or without a change to result_of, I believe there's value in allowing
>> the user to explicitly specify the result_type of a callable object passed
>> to transformed.  Ticket #7748[1] contains a patch which permits that.
>>
>> Thanks,
>> Nate
>>
>> [1] https://svn.boost.org/trac/boost/ticket/7748
>>
>
> I would think a preferable (in the sense of separation of concerns,
> modularity, what-have-you) solution would be an addition to
> Boost.Functional (or whatever) that basically wraps a callable object and
> forces its result_type to be some specified template parameter. E.g.,
>
> template< class F, class R >
> struct result_binder
> {
>   F f;
>   typedef R result_type;
>   template< class... T >
>   result_type operator()(T&&... x) const
>   { return f(std::forward<T>(x)...); }
> };
>
> template< class R, class F >
> result_binder<F,R>
> bind_result(F&& f)
> { return result_binder<F,R>{std::forward<F>(f)}; }
>

I agree that such an object generator (along with Michel's
make_tr1_functor) would be useful.   There are two reasons why I feel
extending transformed would be useful whether or not the previous object
generators were added:

1. Both this and Michel's suggestions require C++11 features -- either
decltype or rvalue references.  Extended transformed allows the creation of
a result_binder struct to be delayed until the reference type of the input
range is available.  This would make it usable for non-lambda instances
where an explicit return type is desired without the fuss of defining a
separate functor (assuming the functor to be wrapped cannot be changed).  I
believe a correct C++03 version of result_binder would need a large number
of operator() overloads depending on how many arguments it intends to
forward.
2. Such a syntax (transformed<R>(...)) has been used previously -- boost
bind's docs, referring to bind<R> syntax, state:  "It is generally used
with function objects that do not, or cannot, expose result_type."[1]
 Without begging for an Emerson quote, I believe consistency with bind in
this case will improve the usability enough to justify the required
changes.  Note also that this is the only current adaptor[2] which takes a
function object with arbitrary return type (others must return something
which is convertible to bool).  Note also that the changes are a pure
extension (previous usage continues unchanged).

Thanks,
Nate

[1] http://www.boost.org/doc/libs/1_52_0/libs/bind/bind.html#Q_forms
[2] I previously proposed a zip/unpack adaptor -- if that were adopted,
unpack would be a second range object which would benefit from an explicit
return type.