Ambiguous Julia methods and f(2, 3)

Let's take it in order. Before writing a third method, put down what each algorithm is supposed to compute for the same integer pair, say (2, 3). Then compare the two.

If they give the same mathematical result there, the intersection method can pick one of them on purpose. Add a few integer-pair examples so the choice is visible to the next reader.

If they disagree, a method that exists only to quiet the ambiguity hides the real question. The integer case then needs a meaning of its own, or callers need a different way to say which operation they want.

The implementation comes last. And please don't reach an existing method by converting one argument to a float. It works, and it buries the very decision the new method was supposed to record.

Less ceremony than ajp's version works too. If integer pairs don't need their own math, the third method can just call the chosen algorithm's helper, and the overlap has one obvious place to go. Put one documented f(2, 3) example beside it so nobody has to work the choice out from the other two signatures.

Seen from R, Julia gets this right. When two S4 methods are equally specific, R doesn't refuse. It picks one by its own ordering rule, prints a note naming the method it chose, and carries on. Notes scroll by. So the integer pair gets an algorithm nobody chose on purpose, and Julia's ambiguity error, annoying as it is, at least forces somebody to choose.

Test.detect_ambiguities on a module holding only the two original methods hands back the (Method, Method) pair without anyone calling f, which beats waiting for the MethodError at some call site.

A second ambiguity hides in the same pair. Bool is a subtype of Integer in Julia, so f(true, 3) is ambiguous too, and once the intersection method exists it goes to the integer-pair algorithm. Whether anyone wants true treated as half of an integer pair is a fresh question, and I doubt it was on anyone's list.