On Mar 18, 12:07 am, Chris Dodd <cd...@[EMAIL PROTECTED]
> wrote:
> The usual way to do this is to compare each function against the list
> of best matches for each argument irrespective of which function they
> came from. That way you get O(nm) complexity in the number of
> candidates and number of arguments. So after looking at #2, you'll
> have (c, c) as your best match argument types and no function that
> matches it. #3 will then match.
Interesting. If I'm reading correctly, you're basically saying that
for the candidate to be an unambiguous best match, all parameters must
have the best match types. Otherwise, the candidate is either one of
several ambiguous matches or incompatible.
Based on this, the resolution process wouldn't know the difference
between an unmatched call and an ambiguous call, and it wouldn't be
able to list the valid candidates for ambiguous cases, but it would
handle correct cases correctly and detect all errors. When an error is
found, error re****ts can be based on an alternative resolution process
- keeping the main resolution process efficient.
I like it.


|