WH>void Foo(int min, int max)
WH>{
WH>    auto predicat = bool lambda( int x ) { return min < x && x <= max };
    
WH>    int count = count_if( ints.begin(), ints.end(), predicat );
WH>    ...
WH>    auto int_it = find_if( ints.begin(), ints.end(), predicat );
WH>    ...
WH>}
WH>

   using namespace boost::lambda;
   count_if(ints.begin(), ints.end(), min < _1 && _1 <= max);

11.2.4. The overload Keyword

Originally, C++ allowed a name to be used for more than one name (that is, "to be overloaded") only after an explicit overload declaration. For example:

overload max; // ``overload'' — obsolete in 2.0
int max(int,int);
double max(double,double);

I considered it too dangerous to use the same name for two functions without explicitly declaring an intent to overload. For example:

int abs(int); // no ``overload abs''
double abs(double); // used to be an error

This fear of overloading had two sources:
[1] Concern that undetected ambiguities could occur.
[2] Concern that a program could not be properly linked unless the programmer explicitly declared which functions were supposed to be overloaded.

The former fear proved largely groundless. The few problems found in actual use are dealt with by the order-independent overloading resolution rules. The later fear proved to have a basis in a general problem with C separate compilation rules that had nothing to do with overloading.

On the other hand, the overload declarations themselves became a serious problem. One couldn't merge pieces of software using the same function name for different functions unless both pieces had declared that name overloaded. This wasn't usually the case. Typically, the name one wants to overload is the name of a C library function declared in a C header. For example:

/* Header for C standard math library, math.h: */
double sqrt(double);
/* ... */

// header for C++ complex arithmethic library, complex.h:
overload sqrt;
complex sqrt(complex);

Now we could write

#include <complex.h>
#include <math.h>

but not

#include <math.h>
#include <complex.h>

because it was an error to use overload for sqrt() on its second declaration only. There were ways of alleviating this: rearranging declarations, putting constraints on the use of header files, and sprinkling overload declarations everywhere "just in case." However, we found such tricks unmanageable in all but the simplest cases. Abolishing overload declarations and getting rid of the overload keyword worked much better.

A>   using namespace boost::lambda;
A>   count_if(ints.begin(), ints.end(), min < _1 && _1 <= max);
A>

struct Point
{
    int x;
    int y;
};
struct Rect
{
    Point p1;
    Point p2;
};
...
count_if(rects.begin(), rects.end(), bool(auto& rect){return min < rect.p1.x && rect.p2.y <= max});

SomeMethod(x : int) : bool
{
    def Greater(y) { x > y }
    def Equals(y)  { x == y }
    def GreaterOrEquals(y)  { Greater(y) || Equals(y) }
    
    if (GreaterOrEquals(10))
        ...
    else if (GreaterOrEquals(2))
        ...
    else if (Equals(1))
        ...
    ...
}

A>I considered it too dangerous to use the same name for two functions without explicitly declaring an intent to overload. For example:...

A>>   using namespace boost::lambda;
A>>   count_if(ints.begin(), ints.end(), min < _1 && _1 <= max);
A>>

count_if(begin(), end(), fun x => min < x.p1.x && x.p2.y <= max);

WH>struct Point
WH>{
WH>    int x;
WH>    int y;
WH>};
WH>struct Rect
WH>{
WH>    Point p1;
WH>    Point p2;
WH>};
WH>...
WH>count_if(rects.begin(), rects.end(), bool(auto& rect){return min < rect.p1.x && rect.p2.y <= max});
WH>

    return count_if(ints.begin(), ints.end(), min < &(&_1 ->* &Rect::p1) ->* &Point::x && max <= &(&_1 ->* &Rect::p2) ->* &Point::y);