<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 8 April 2013 13:37, Manu <span dir="ltr"><<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div></div><div class="gmail_extra"><div class="gmail_quote"><div>Oh my god... ..... this is the most upsetting thing I've heard all day! :(</div><div>No really, I have been SOOOO excited for so long about this optimisation potential in D!</div>

<div>There's gotta be something that can be done! >_<</div><div><br></div><div>Does the front end know if the function actually DOES assign to any state? The compiler could easily work that out, and in the event it doesn't actually perform any such assignment, it could be marked pure for reals...</div>
<br></div></div></div></blockquote></div><br></div><div class="gmail_extra">Haven't looked, but it appears to have a general idea of this.  D 'weak pure' and 'const pure' may update an internal state (had the latter bite me hard once).  The only case where 'strong pure' might do this is by throwing an exception or an assert being thrown - this changes program state so can't be marked pure.<br>
<br></div><div class="gmail_extra">So having identified this, we can safely say that functions could only be 'C pure' in the following case:<br></div><div class="gmail_extra">- Compiled function is 'strong pure'<br>
</div><div class="gmail_extra">- Compiled function is 'nothrow'<br></div><div class="gmail_extra">- We are compiling in release mode.<br clear="all"></div><div class="gmail_extra"><br></div><div class="gmail_extra">
Only then we (the frontend) can safely say that 'this function has *absolutely* no side effects, so can be marked as pure'.   Pure is never inferred.<br></div><div class="gmail_extra"><br>-- <br>Iain Buclaw<br><br>
*(p < e ? p++ : p) = (c & 0x0f) + '0';
</div></div>