<div class="gmail_quote">On Fri, Sep 9, 2011 at 11:01 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I hate to pull out the bikeshed paint... But why not!<div class="im"><br><br><div class="gmail_quote">On Fri, Sep 9, 2011 at 10:56 AM, Kaelyn Uhrain <span dir="ltr"><<a href="mailto:rikka@google.com" target="_blank">rikka@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I moved TDK_InvalidExplicitArguments to rank 5 and made TDK_Too*Arguments rank 6 since I feel it's slightly more likely that someone gave the wrong argument to a template than to have the wrong number of arguments (with candidates needing the wrong number of arguments being a more common case, especially candidates that are way way out in left field).</blockquote>

</div><br></div><div>I'm not sure actually. I often leave one argument off the end of a function. I don't think that's too unlikely.</div><div><br></div><div>Ah, I think I know what I really want here.</div><div>
<br>
</div><div>If the arguments that are specified match the parameters, but there simply aren't enough or is one too many, I would rank that candidate before an explicit argument mismatch.</div><div><br></div><div>If the arguments don't match the parameter types *and* there are too many or not enough, I would rank that candidate after.</div>

<div><br></div><div>Is that feasible to implement?</div>
</blockquote></div><br>The catch is that there is only a single reason given for failure... I haven't looked at the overloaded-template deduction code so I'm not sure if, in the case that an explicit argument doesn't match the parameter type *and* the wrong number of args are given whether the result is TDK_InvalidExplicitArguments or TDK_TooManyArguments/TDK_TooFewArguments. Your proposal would require adding an additional TemplateDeductionResult value that indicates both invalid explicit arguments and the wrong number of arguments, plus possibly nontrivial changes for the deduction code to detect both and record it instead of (possibly) stopping checking once one or the other is true.<br>
<br>One reason I chose to rank TDK_InvalidExplicitArguments above TDK_Too*Arguments is the theory that there are likely more failed candidates with the wrong number of arguments than failed candidates because of an invalid explicit argument. Currently the more general comparison function/struct (CompareOverloadCandidatesForDisplay) it always sorts arity mismatches (in non-template-deduction-failure cases) after all other candidates, and if nothing else sorting TDK_InvalidExplicitArguments before TDK_Too*Arguments provides consistency with CompareOverloadCandidatesForDisplay within the scope of template deduction failures.<br>
<br>And for what it's worth, I think adding new values to TemplateDeductionResult to be able to do things like sort some arity mismatches before other template deduction types with other arity mismatches after those types to be better suited for a separate patch as it involves more changes to the actual overload resolution and/or template deduction code. This patch is just about making the comparison function used to sort the candidates for display a bit smarter based on already available information.<br>
<br>Cheers,<br>Kaelyn<br>