Function and operator overloading

Hi. Please excuse me if this has been discussed to death earlier. I've tried to search for it, but I've come up empty: https://www.php.net/results.php? q=function+overloading&l=en&p=all The recent discussion on operator overloading has highlighted the relationship between function overloading and operator overloading, and how having support for the former may help provide the latter. For those with experience with C++, function and operator overloading works the same way, and the only difference is that operator overloading is defined as a function of the form "operator+(...)", i.e. "operator" followed by the operator itself. I know that C++'s system for overloading is very complex (because it has something called partial ordering of functions, and it also includes templates/generics). Nevertheless, I think it could be possible to implement a subset in PHP, without all the complexity, and in this way provide a cleaner way of implementing either kind of overloading, and avoiding the "closed set" / library interaction issues mentioned in the other thread. What I have in mind is to let the parameter types of a function become part of the function name, something like this: // Function overloads function add(Money $a, Money $b): Money { ... } function add(Matrix $a, Matrix $b): Matrix { ... } // Operator overloads function operator+(Money $a, Money $b): Money { ... } function operator*(Money $a, Percentage $b); Money { ... } function operator*(Matrix $a, Matrix $b): Matrix { ... } Use: $m1 = new Money(100); $m2 = new Money(200); $p = new Percentage(10); $result = $m1 + $m2; // Money(300) $result = $m1 * $p; Money(10) I realise that including the parameter types as part of the (internal) name of a function is a major departure from the way PHP works today. However, if we are to grow PHP into the future, and continue to provide clean ways of expressing things, then maybe we should re-examine such fundamental things, where a clean interface and simplicity for the developer is more important than implementation complexity. Regards, Terje