On 9/5/2012 2:54 AM, Joel de Guzman wrote:
On 9/5/2012 1:46 PM, Daniel Walker wrote:
OK, I think there's something we can do about this. I've attached a modification of your sample code that uses a simple is_callable metafunction predicate with enable_if so that SFINAE can kick in. It's a proof of concept. I'm not familiar with Eric's can_be_called
I describe the technique here: http://www.boost.org/doc/libs/1_51_0/doc/html/proto/appendices.html#boost_pr... And there is a feature request to add this metafunction to Boost.Function_types, with reference implementation, here: https://svn.boost.org/trac/boost/ticket/3783 That ticket is now 3 years old. Tobias, any interest in it?
so I don't know if these metafunctions test exactly the same thing. My is_callable tests if a valid call expression can be constructed from a result_of-style signature; i.e. can the signature be used with result_of to get a result type.
This is a good solution.
Now, this could be folded into result_of; e.g. result_of could inherit from enable_if_lazy<is_callable<...>, ...>, or something like that, if you follow me. Is it worth fleshing this out? Or should we just leave it as a known (and soon to be documented) difference in behavior between TR1 and decltype-based result_of?
I would be opposed to folding this into boost::result_of both because of the metaprogramming overhead, and also because I don't want to encourage people to do something that will make it harder for them to port their code to std::result_of later. A separate metafunction would be useful, or an is_callable_with_args trait. That said, it's an interesting suggestion, and if I can find a light-weight solution, I might float it with the standardization committee and see if there is interest.
I'm not sure. To me, I think it's easier to simply avoid result_of on C++11 and just use decltype directly. Problem solved. Why use an inferior tool when something better is available anyway?
In the case where you need an overload to drop out because of the ill-formed-ness of a call expression, I agree with you. If you mean to swear off using result_of entirely because of this issue, then you'd be making your code non-portable for no good reason. -- Eric Niebler BoostPro Computing http://www.boostpro.com