Re: [boost] painless currying

Subject: Re: [boost] painless currying
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-08-28 07:06:29

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:
>
>> On Sat, Aug 27, 2011 at 2:43 PM, Michael Caisse<
>> boost_at_objectmodelingdesigns.**com <boost_at_[hidden]>>
>>  wrote:
>>
>>  On 08/24/2011 08:13 AM, Eric Niebler wrote:
>>>
>>>  On 8/24/2011 1:58 AM, Roman Perepelitsa wrote:
>>>>
>>>>  I think this is the case with functors generated by bind -- they appear
>>>>
>>>>> to
>>>>> be callable with any number of arguments.
>>>>>
>>>>>  Ouch. :-(
>>>>
>>>> One option, which I don't like, is to "fix" bind to disable any
>>>> operator() overloads that result in an invalid invocation of the bound
>>>> function. That can be done easily with the is_callable_with metafunction
>>>> in my curryable implementation, but would reduce portability somewhat.
>>>>
>>>>
>>>>  That isn't "broken" behavior. Very often that is exactly what you want
>>> from
>>> bind.
>>>
>>>  Why would you prefer enabling operator() overloads of bind that result
>> 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:
>
>
>   void log( std::string name, timestamp_t stamp );
>   ...
>
>   function<void(std::string,**timestamp_t)> notify = bind( &log, _2, _1 );
>   ...
>
>   notify( timestamp, source, lat, long, message );
>
>
> 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