Rethinking overload resolution #33
Description
The current approach is basically as follows:
Every type conversion has a score, the lower the score is the more preferred this conversion is. If ever a type can't be converted into what the function expects the whole thing returns -1. The individual scores get added up per argument and the function which achieves the smallest score gets picked as the overload.
While this approach is fairly simple and works in trivial cases (normal program usage), it has several shortcomings.
There is no mechanism to be able to differentiate based on the order of arguments. It's always the lowest score that wins. If for instance you have two functions where one has the scores [1, 1, 5] it would clash with a function that has scores [2, 2, 3]. It is unclear if in this case there would be a preferred overload.
Another problem arises with vararg functions, because the distance keeps increasing for every argument which makes a function that accepts more arguments of a more "correct" type less likely to be picked over a function that does more type conversions on a fixed number of arguments. Again it is unclear what the actual intent was.
The upside is that these cases are rare and I haven't actually encountered one where it would matter. Still, this is a hole in a potential spec for the language which should be more thoroughly defined for these edgecases.