Re: [boost] painless currying

Subject: Re: [boost] painless currying
From: Michael Caisse (boost_at_[hidden])
Date: 2011-08-28 17:04:32

On 08/28/2011 04:06 AM, Jeffrey Lee Hellrung, Jr. wrote:
> On Sat, Aug 27, 2011 at 10:00 PM, Michael Caisse<
> boost_at_[hidden]>  wrote:
>
>> On 08/27/2011 04:20 PM, Jeffrey Lee Hellrung, Jr. wrote:
>>
>>
<snip>
>>> in a
>>> compiler error over "SFINAE-disabling" them?  (Other than compile time
>>> considerations and minimizing complexity.)
>>>
>>> - Jeff
>>>
>> Hi Jeff -
>>
>> I might be confused. I thought we were talking about the bound functor
>> allowing a different number of arguments than the function that it is bound
>> to. For example, more arguments like this:
>>
>>
<snip>
>>
>> There is no error here. Have I missed the point?
>>
> As far as I understood it, yes.  As I understood Eric's proposal, "bind(
> &log, _2, _1 )( timestamp, source, lat long, message )" would still compile
> fine, but "bind(&log, _2, _1 )( 0.0, (void*)(0) )" (for example) would
> result in a compiler error *at the call site* due to operator() overloads
> within boost::bind function objects (whatever those implementation objects
> are) being SFINAE-disabled for any argument binding that results in an
> "invalid invocation of the bound function".  This behavior requires
> something like Boost.Proto's can_be_called (I may have the precise name
> wrong here...) machinery to implement.  This buys one the ability to
> likewise use function object types returned by boost::bind in the same
> can_be_called machinery to enable compile-time introspection of *that*
> type.  In the context of this thread, this allows one to decide when an
> argument passed to a curried function triggers the underlying function to be
> evaluated.
>
> HTH,
>
> - Jeff
> _______________________________________________

Thanks Jeff. I guess I wasn't following close enough  (o;

-- 
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com