[C++-sig] strange behavior with respect to numeric and Booleanoverloads

[Ralf W. Grosse-Kunstleve]

> Agree with the decision to #ifdef it... This might be worse than
> first-match, and the overload-order-bug has been around a long time
> without surfacing.

I wouldn't say it is a bug, more a missing feature. Dave and I knew
about the drawbacks from the start, but we didn't have the time for the
comprehensive solution. I've been using Boost.Python heavily for 8+
years now, and it has only been a few times that I found the simple
first-match solution annoying. In the worst case, you just give the
overloads different names in Python. (I don't know how easy this is
with Py++, though.)

> It'd be hard to justify going that direction. Note that exactly the
> same situation exists for float and int,

There is an important difference: int and float are numeric types.
bool really isn't (I think it is highly undesirable that bool and
int are implicitly convertible in Python and C++).

In a very early stage of the Boost.Python v2 reimplementation,
even str matched float or int!

bool matching float or int is similar, only we couldn't do anything
about it since bool didn't exist as a type in Python 2.2, which is
all we had during the v2 reimplementation.

> So with strict checking turned *on*, you disambiguate manually:
> 
>  foo(bool(1), 'hi')
>
> but turning on strict checking breaks all kind of stuff.

It wasn't that bad for me, just a little boring having to retrofit the
mountains of old code. The end-result is cleaner, so it's worth it.
But it think it would be bad to force it on people. We need a soft
approach, so that everybody can do it at his own schedule.

>  For the
> vast majority of cases, it seems, what's there is fine.  So either
> grok and implement something like d. wallin / luabind's method,
> as dave suggests.

I haven't thought about this very much at all, so this may be stupid:
Could the C++ template matching rules be a role model? These rules
are time tested and I believe are very well spelled out.

> and both are wrapped, and I'm in python and want the second one, how about
>
>   foo[ (bool, string) ](1, 'hi')

That seems like it could be a lot of work to implement, and it would be
very unusual. You can achieve the same via:

  foo_int_string(1, 'hi')
  foo_float_string(1, 'hi')

In the few cases that I had the int/float problem, on second thought
it turned out to be better to use more telling (different) names for
the functions. I.e. I never found myself resorting to appending the
argument type names.
Another nice solution is to disambiguate via keywords.

Ralf