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-22 12:13:07

Hi Niel,

Neil Groves wrote:
>
>
> I've definitely considered this issue in the context of Boost.Range and
> have as yet failed to come up with anything that works well enough without
> problems. I need to spend some time looking at the Michel Morin
> contribution.
>
> I do not intend releasing a change to Boost.Range that allows code to
> compile that has edge cases that are easy to fall into that cause major
> problems. In practice it might be necessary to conditionally enable this
> feature for a subset of the supported compilers. I am totally convinced of
> the additional values that Boost.Range interoperation with lambdas provides
> and this is therefore worth lots of effort.
>
> In the interim solution proposals are very welcome. It could well be that
> I haven't thought of something simple that is generally safe.
>
> I think mimicking bind's double form[1] would be best when needed.  This
would require the transformed adaptor to be changed to a function, but
would allow the following usage:

Uses result_of (with boost::phoenix):
float val = boost::accumulate(seq | transformed(px::at_c<0>(arg1)), 0.f);

Can't use result_of:
float val = boost::accumulate(seq | transformed<float>([](const
boost::tuple<float, int, MyType>& tup) { return boost::get<0>(tup); }),
0.f);

I have done this in the past with my zip & unpack adaptors and it has
worked well -- I only use the secondary syntax with lambdas, and once I'm
on compilers that use decltype for result_of, I just won't need to use it.

Would you consider a patch which changed transform (and transformed) to
allow this?  I would ensure that current tests still pass.

Thanks,
Nate