Joe Buck wrote:
> And this, of course, means we have to define relevance. There are two
> cases: the first is when we fail to choose an overload because of
> ambiguity; there we can just report all of the choices that are tied for
> "equally good". The other case is where no overload matches. There
> we could try to produce a heuristic that would "score" each alternative.
> Matching some but not all of the arguments would contribute some points,
> likewise if the addition or removing a const qualifier would cause a
> match, that would score points. It would take some tweaking to produce
> a meaningful result.
Hmm, I'm not a language lawyer, but isn't there already a well-ordered
definition of more or less closely-matching in the whole C++ name resolution
thing? It could be confusing if our warnings operated a significantly
different standard for what's close and what's not than that defined in the
language spec, but in terms of doing what the user meant, we'd probably want
to treat certain mismatches as more significant than others for diagnostic
purposes (e.g. the common char[] vs char * when passing a const string problem).
So I guess, yes, I'm asking Arthur to suggest rules of relevance that would
enable the compiler to decide what kind of user error is implied by a given
syntax error.
cheers,
DaveK
