Re: [boost] [result_of] now uses decltype on release branch

Subject: Re: [boost] [result_of] now uses decltype on release branch
From: Eric Niebler (eric_at_[hidden])
Date: 2012-09-05 11:33:31

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_proto.appendices.implementation.function_arity

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