<div class="gmail_extra"><div class="gmail_quote">On 18 December 2012 16:58, Iain Buclaw <span dir="ltr"><<a href="mailto:ibuclaw@ubuntu.com" target="_blank">ibuclaw@ubuntu.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="gmail_extra"><div class="im"><div class="gmail_quote">On 18 December 2012 16:43, Peter Alexander <span dir="ltr"><<a href="mailto:peter.alexander.au@gmail.com" target="_blank">peter.alexander.au@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:<br>
</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Should we take this as an opportunity for other compiler maintainers to implement their own compiler-specific predefined attributes?<br>
</blockquote>
<br></div>
Please, no!<br>
<br>
Suppose GDC implements @noreturn (or whatever other attribute)<br>
<br>
Later, LDC implements @noreturn separately with slightly different semantics.<br>
<br>
We now end up in a situation where @noreturn cannot be used portably, and neither compiler developer has incentive to change (whoever changes breaks their users code).<br>
<br clear="all"></blockquote></div><br></div>Provide a situation where @noreturn attribute would mean anything other than telling the compiler to assume that the function<code></code> cannot return, and I might please you on *that* particular attribute.<br clear="all">
</div></blockquote></div><br>Might believe you. :=)<br><br>-- <br>Iain Buclaw<br><br>*(p < e ? p++ : p) = (c & 0x0f) + '0';<br>
</div>