<div dir="ltr">Hello, John!<div><br></div><div>Thanks for your comments!</div><div style>I introduced a flag that allows noreturn mismatches only if template deduction is called during overload resolution.  It allowed also to use function calls only in these cases while just comparing pointers in all the other cases.</div>

<div style><br></div><div style>Just comparing types will not work unless noreturn and non-noreturn functions have the same type, but this is not the thing we want according to the recent discussion on PR15105.  While it is possible to build a similar function type without noreturn and compare against it, this would not work for implicit default calling conventions that require the same logic in overload as noreturn functions.</div>

<div style><br></div><div style>Is this patch better?</div><div style><br></div><div style>--</div><div style>Alex</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 26 February 2013 02:48, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Feb 25, 2013, at 8:34 AM, Alexander Zinenko <<a href="mailto:ftynse@gmail.com">ftynse@gmail.com</a>> wrote:<br>


> This patch allows function templates with GNU noreturn attribute to participate in overload resolution as non-noreturn ones.  Same behavior is allowed for functions now.<br>
> The patch only allows deducing such types since the necessary adjustments are already performed in corresponding functions (like in IsStandardConversion).<br>
<br>
</div>This function does a lot of work to make sure that the final equality comparison is a (fast) pointer equality test, and you're replacing it with a (slow) function call.<br>
<br>
Also, we definitely don't want to allow noreturn mismatches in every context.<br>
<span class="HOEnZb"><font color="#888888"><br>
John.<br>
<br>
</font></span></blockquote></div><br></div>