I had the same issue and posted it a few months ago. I wrote to the MS VS forum that their
std::result_of should work correctly with both old and new formats; in particular use the
declared result_type if it exists (which in general lets the user override the deduced
type, great for compatibility issues).
Actually doing that robustly is a bit of a maze of metaprogramming. I ended up making a
local my_namespace::result_of that I just handles what I needed, and only when I asked for
it. That doesn't help the existing range templates, but such a change could be put back
into boost::result_of.
Meanwhile, for different reasons, I made a macro that abstracts the different syntax
between C++11 lambdas and Apple Block Closures. The latter generates a suitable lambda
class complete with result_of member. That makes me think that you could have a macro that
wraps a compiler-generated lambda expression in another class that inherits the operator()
etc. and adds in the result_of typedef to simply use decltype.
—John
Date: Wed, 21 Nov 2012 10:15:18 -0700 From: Nathan Crookston
Can the last line, labelled NOT Ok, be made to work? I think the lambda does not publish its result as a bind does, so I suspect it's hopeless. Any thoughts? // NOT Ok boost::range::push_back( out, in | transformed( []( S & s ) { return s.i; } ) ); }
It seems trivial to have a nested result_type in all cases with a lambda. However, in C++11 there's no need for it due to decltype.
Sadly, some compilers fall into a gap where result_of (boost or std) doesn't use decltype and lambdas don't publish tr1-style result_type -- leaving code like the above in the lurch.
Michel Morin wrote some code for adapting such a case which may be of interest to you: http://lists.boost.org/boost-users/2012/01/72879.php
HTH, Nate