Function/method overloading is about calling different functions depending on the types of the arguments:
cdef int min(int a, int b): return a if a <= b else b cdef float min(float a, float b): return a if a <= b else b
So, whenever min is called the arguments are first checked for an exact match, then automatic conversions are tried until an unambigious match is found. If the match is ambigious or there is no match it is a compile-time error.
As C++ developers know, it is almost a necessity when working with typed code if one is working with multiple data types. These kind of functions often also can replace macros.
Also, when combined with templates it makes it possible to write Python-like generic "duck-typed" code that still is efficient.
The proposal is to restrict this to cdef functions only, and doesn't do anything to figure out which type of "object" to influence on which method to choose.
While overloaded Python functions could in theory be supported by generating run-time checks on the arguments to see in which direction they would most readily convert, this is probably better left for explicit code/manual wrappers.
In C++ the return type is not allowed (as in many situations the return type might be ignored and unspecificed while parameters are always mandatory). One might want to be consistent with this.
However, allowing it would allow a simple __coerce__ operator declaration for declaring possible coercions (C++ handles this by having the typename in the method signature for the cast operator, double operator double(), which is basically a way of allowing overloading on return types in that specific case).
Also it would solve things like the getitem operator needing different return types depending on parameters (the method to use would be decided on the needed return type, and one would use assertions on the method arguments in addition).
Overloaded functions must simply have their names mangled in C output, and calls replaced correspondingly.
Also, if outputting C++ code, one could simply leave the name mangling to C++ (ie an optional mode for when outputting C++ code that would integrate better with debuggers etc. - outputting C code should still be supported though).
Potential problems: Using a name mangling policy that will work across different compiled modules will probably be difficult, especially since we (unlike C++) don't know the full type of typedef-ed symbols.
Potential solutions: First see what C++ has done in details and see if we get any more ideas. But for now: a) Leave it for now (don't support overloading exported functions). b) Allow exporting functions but require a special "mangled name" to be declared as well in the pxd file. c) If precompiled pxd support arrives then the mangling could be done in the precompilation stage, enabling one to store the mangling together with the pxd (however recompilation of the pxd would break "binary" compatability...so probably not!).