<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px">> OK, but that may involve changing system headers<br style="" class=""><br style="" class="">The current diagnostics may require changing system headers as well. In the<br style="" class="">real world it's not as simple as f -> g -> h. See<br style="" class="">[here](https://github.com/ericniebler/range-v3/issues/94) where the user<br style="" class="">modifies library headers to diagnosis the problem.<br style="" class=""><br style="" class="">> Nonetheless, I don't think you have evidence for your "90%" claim<br style="" class=""><br style="" class="">Granted I didn't do a complete survey, and measuring complaints is invalid<br style="" class="">since the complaints about the proposed feature are non-existent. However,<br style="" class="">from my personal experience using this patch, I have yet to see a need for<br style="" class="">full backtrace. There is probably is a need for it, but it is very small.<br style="" class=""><br style="" class="">> We know how to make all the cases better: if there's only one viable<br style="" class="">> candidate, provide a full instantiation backtrace for it -- why not do that<br style="" class="">> instead?<br style="" class=""><br style="" class="">That is my end goal. At least to have a compiler flag for it as well. However,<br style="" class="">it is a much larger task and requires possibly refactoring<br style="" class="">`DeductionFailureInfo` to store a complete trace. I don't work on clang full<br style="" class="">time so this will take awhile. So I figured with this patch, users can benefit<br style="" class="">from better error messages now.<br style="" class=""><br style="" class="">Paul<br style="" class=""><br style="" class=""><div id="yui_3_16_0_1_1426871130915_1536738"><span></span></div> <br><div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <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" size="2"> On Monday, April 6, 2015 5:39 PM, Richard Smith <richard@metafoo.co.uk> 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 class="y_msg_container"><div id="yiv5315384496"><div><div dir="ltr"><div class="yiv5315384496gmail_extra"><div class="yiv5315384496gmail_quote">On Mon, Apr 6, 2015 at 3:06 PM, paul Fultz <span dir="ltr"><<a rel="nofollow" shape="rect" ymailto="mailto:pfultz2@yahoo.com" target="_blank" href="mailto:pfultz2@yahoo.com">pfultz2@yahoo.com</a>></span> wrote:<br clear="none"><blockquote class="yiv5315384496gmail_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="yiv5315384496">> The difference is, the current diagnostics allow the user to figure out what<br clear="none">> happened. This change does not -- there's no way to find out which 'f' caused<br clear="none">> the problem, and how we got from 'f' to 'g'.<br clear="none"><br clear="none"></span>Yes, the user can still figure out how you got from `f` to `g`. The user can<br clear="none">either add an extra overload for `g` or comment out `g`(and continue so until<br clear="none">the user gets to `f`). So instead of working forwards from `f` to `g`, the<br clear="none">user just works backwards from `g` to `f`. However, its less likely a user<br clear="none">would need to do that since 90% of the time users want to get to `g` and not<br clear="none">to `f`.</span></div></div></div></blockquote><div><br clear="none"></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 class="yiv5315384496yqt6812174390" id="yiv5315384496yqtfd00967"><div><br clear="none"></div><blockquote class="yiv5315384496gmail_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="yiv5315384496HOEnZb"><font color="#888888">Paul<br clear="none"></font></span></span></div><div><div class="yiv5315384496h5"> <div dir="ltr"><span><br clear="none"></span></div><br clear="none"><div><br clear="none"><br clear="none"></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 rel="nofollow" shape="rect" ymailto="mailto:richard@metafoo.co.uk" target="_blank" href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br clear="none"> </font> </div> <blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;margin-top:5px;padding-left:5px;"> <br clear="none"><br clear="none"> <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" shape="rect" ymailto="mailto:pfultz2@yahoo.com" target="_blank" href="mailto:pfultz2@yahoo.com">pfultz2@yahoo.com</a>></span> wrote:<br clear="none"><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 clear="none"><br clear="none">
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 clear="none">
<span><br clear="none">
> If we produced a stack of 'in instantiation of' notes, this would be fine<br clear="none">
<br clear="none">
</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 clear="none"></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 clear="none"></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 clear="none">
<br clear="none">
</span>That seemed to be more of a hack then something to be used in production.</blockquote><div><br clear="none"></div><div>Yes, absolutely, that change is not production-ready.</div></div></div></div></div><br clear="none"><br clear="none"></div> </blockquote> </div> </div> </div></div></div></div></div></blockquote></div></div><div class="yiv5315384496yqt6812174390" id="yiv5315384496yqtfd43204"><br clear="none"></div></div></div></div></div><br><br></div> </blockquote> </div> </div> </div></div></body></html>