Do any of your examples (generic programming, templates, Boost libraries) actually utilize the concept of testing the truthiness of an object of unknown type? I think your criticism is invalid. I like generic programming in Java, though I admittedly have not used templates or Boost libraries for anything substantial.

> In Python it absolutely, positively, without a doubt is not a bad thing to have a function which accepts multiple data types. Some trivial examples are len() and iter().

I'm not arguing that this shouldn't be the case. My argument is specifically about bool(). If len() or iter() worked as strangely with basic data types as bool(), then I would probably extend my argument to cover them as well. For any data type I'm aware of that works with len() or iter(), the logic of what is returned is pretty clear and obvious, but that's not the case (in my opinion) with bool(). If len(-5) returned 5 (i.e. absolute value or "length from zero") then I would argue that it's a bad idea.

C++ doesn't have unknown types, so we're working with different definitions. Here's an example:

    [xebulon:~/tmp] dalke% cat tmp.cc
    #include <iostream>
    
    template<typename T>
    int f(T s) {
     return s ? 2 : 0;
    }
    
    main() {
      std::cout << "int 0 " << f(0) << std::endl;
      std::cout << "int 8 " << f(8) << std::endl;
      std::cout << "float 0.0 " << f(0.0) << std::endl;
      std::cout << "float -1.0 " << f(-1.0) << std::endl;
    }
    [xebulon:~/tmp] dalke% g++ tmp.cc
    [xebulon:~/tmp] dalke% ./a.out 
    int 0 0
    int 8 2
    float 0.0 0
    float -1.0 2

The function f() doesn't know the type, but its instantiation for f(0) (integer) and f(0.0) float know the type.

C++ containers don't have a bool (or at least vector<> doesn't). For one, until C++11 there was no "explicit operator bool", and a simple "operator bool" was too permissive because of implicit type conversion. C++11 introduced a more contextual conversion to bool.

More and more components have explicit bool support. For example, http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/shared_p... ?

    Notes: This conversion operator allows shared_ptr objects to be
    used in boolean contexts, like if(p && p->valid()) {}.

    [The conversion to bool is not merely syntactic sugar. It allows shared_ptrs
    to be declared in conditions when using dynamic_pointer_cast
    or weak_ptr::lock.]

and http://en.cppreference.com/w/cpp/memory/unique_ptr/operator_... .

I do not track C++ well enough to go into any more depth than this, especially as it concerns the history and future.

I like to say "if x: ..." and not "if len(x) == 0:" in order to check if a dictionary is empty.

Following Scheme, I can understand that something like "if empty(x)" might be more explicit. But I have a decent amount of code where I do something like:

   def process(a, rename=None):
     if rename:
       a = [rename.get(x, x) for x in a]
     ... do things with a ...

In this toy example, "rename=None" indicates that there is no renaming dictionary, and using {} as the renaming dictionary won't rename anything, so the "if rename" tests for both conditions correctly.

Without bool, I could write it as:

     if rename is not None:

since using the empty dictionary in this case is okay, but if I want the slight extra performance for the empty dictionary case I would have to write it:

     if rename is not None and not empty(rename):

I think that would grow tedious.

BTW, I don't use "def process(a, rename={}):" because that is one of Python anti-patterns: the default values are constant over the life of the function, so

    def something(a, b={}):
      b[a] = a
      return b

will accumulate to b rather than create a new dictionary each time. Thus, seeing a "={}" or "=[]" in a parameter list demands closer inspection because it often leads to errors.