Am Mon, 8 Apr 2013 16:40:34 +0100 schrieb Iain Buclaw <[email protected]>:
> On 8 April 2013 13:37, Manu <[email protected]> wrote: > > > Oh my god... ..... this is the most upsetting thing I've heard all > > day! :( No really, I have been SOOOO excited for so long about this > > optimisation potential in D! > > There's gotta be something that can be done! >_< > > > > 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... > > > > > 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. > > So having identified this, we can safely say that functions could > only be 'C pure' in the following case: > - Compiled function is 'strong pure' > - Compiled function is 'nothrow' > - We are compiling in release mode. > > 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. > Can't a strong pure + nothrow + release mode function still throw errors? Or is this the "we don't guarantee anything regarding Errors" case and we just don't care?
