All, Jeffrey Lee Hellrung, Jr. wrote:
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.
Maybe this is what you did, so I might not be suggesting something new, but... Perhaps boost::result_of could have an extra conditional logic branch added to it: - If F::result_type exists, return F::result_type; - Else: - If BOOST_NO_CXX11_DECLTYPE, return F::result< F ( Args... ) > - Else, if F::result<> exists, return F::result< F ( Args... ) > - Else return decltype( declval<F>() ( declval< Args >()... ) )
I like this -- it sounds like what John describes, but also using the result struct. I'd suggest that structure if neither BOOST_RESULT_OF_USE_DECLTYPE nor BOOST_RESULT_OF_USE_TR1 are defined (and BOOST_NO_DECLTYPE_N3276 is defined). Those who have been working on result_of the most lately haven't been on this thread; I'll post this with a new subject to see what they say. 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