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