Peter and David (and others :-) Boost.bind currently has the limitation that a binder will not be invoked with non-const rvalues, as was very nicely explained in the "Forwarding Problem" (document http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm). In that paper, you discuss a possible solution which you deem impractical, i.e. to add all 2^N overloads mixing & and const& for the invocation arguments. Indeed, Boost.bind already supports 9 arguments and 2^9 is a large number... However, I fail to see the shortcoming in the following approach: add 2*N (not 2^N) overloads, one set of N where all arguments are taken as &, and another set of N where all the arguments are taken as const&. If any invocation argument is a non-const lvalue, then all arguments will be taken as & (first set of overloads) since this is the only one that will match. And if all arguments can be passed to a const&, then the second set of overloads will provide a better match than the first, hence no ambiguity. Such an extension would allow boost.bind to forward non-const rvalues, in the case where none of the arguments is a non-const lvalue. So the example showing the limitation of the current solution #1 in the document cited above will then work. You still will not be able to forward a mix of non-const lvalues and rvalues, but it may not happen very frequently (most return arguments I use in my code are passed by address, in C style, and an address can be matched to a "T* const&"). Also, the cost is not high (what's an extra 9 overloads, when you already have 9 :-) My question is: Is there something I am missing that would create problems in the usage of Boost.bind, if the second set of overloads were added (besides the inconvenience of more overloads and a longer source code to parse for the compiler)? BTW, I am not necessarily advocating that Boost.bind provide the const& overloads, although I think it would be nice if there are no problems associated with it. Thanks for any thoughts, -- Herve Bronnimann