<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 6, 2015 at 3:06 PM, paul Fultz <span dir="ltr"><<a href="mailto:pfultz2@yahoo.com" target="_blank">pfultz2@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div dir="ltr"><span><span class="">> The difference is, the current diagnostics allow the user to figure out what<br>> happened. This change does not -- there's no way to find out which 'f' caused<br>> the problem, and how we got from 'f' to 'g'.<br><br></span>Yes, the user can still figure out how you got from `f` to `g`. The user can<br>either add an extra overload for `g` or comment out `g`(and continue so until<br>the user gets to `f`). So instead of working forwards from `f` to `g`, the<br>user just works backwards from `g` to `f`. However, its less likely a user<br>would need to do that since 90% of the time users want to get to `g` and not<br>to `f`.</span></div></div></div></blockquote><div><br></div><div>OK, but that may involve changing system headers, which is significantly more difficult in some cases. Nonetheless, I don't think you have evidence for your "90%" claim, so this would take us from one "not enough information is provided" case to another, which will make some cases better and others worse. We know how to make all the cases better: if there's only one viable candidate, provide a full instantiation backtrace for it -- why not do that instead?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div dir="ltr"><span><span class="HOEnZb"><font color="#888888">Paul<br></font></span></span></div><div><div class="h5">  <div dir="ltr"><span><br></span></div><br><div><br><br></div><div style="display:block"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div dir="ltr"> <font face="Arial"> On Monday, April 6, 2015 4:24 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br> </font> </div> <blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;margin-top:5px;padding-left:5px">  <br><br> <div><div><div dir="ltr"><div><div>On Mon, Apr 6, 2015 at 2:08 PM, Paul Fultz II <span dir="ltr"><<a rel="nofollow" href="mailto:pfultz2@yahoo.com" target="_blank">pfultz2@yahoo.com</a>></span> wrote:<br><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> gives the user no idea of how we got from a call to f into a call to g.<br><br>
For the default case, its better to show the first and last in the trace, as most users don't care about the intermediate steps.<br>
<span><br>
> If we produced a stack of 'in instantiation of' notes, this would be fine<br>
<br>
</span>Yes, the full back trace can be added in the future(perhaps as a compiler flag). This is the first step towards that direction. There needs to be some refactoring to `DeductionFailureInfo` so it stores the entire diagnostics(rather than a single diagnostic) to make a full back trace possible.</blockquote><div><br></div><div>The difference is, the current diagnostics allow the user to figure out what happened. This change does not -- there's no way to find out which 'f' caused the problem, and how we got from 'f' to 'g'. Hence this patch is not acceptable as-is -- not even as a stepping stone to something better.</div><div><br></div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> note that's exactly what my patch in comment#1/comment#2 of that bug does<br>
<br>
</span>That seemed to be more of a hack then something to be used in production.</blockquote><div><br></div><div>Yes, absolutely, that change is not production-ready.</div></div></div></div></div><br><br></div> </blockquote>  </div> </div>   </div></div></div></div></div></blockquote></div><br></div></div>