On Sat, Aug 27, 2011 at 10:00 PM, Michael Caisse < boost@objectmodelingdesigns.com> 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@objectmodelingdesigns.**com <boost@objectmodelingdesigns.com>> 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