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