On 8 April 2013 14:32, David Nadlinger <[email protected]> wrote: > On Monday, 8 April 2013 at 12:37:48 UTC, Manu wrote: > >> On 8 April 2013 21:46, Iain Buclaw <[email protected]> wrote: >> >>> Only builtins are pure in the sense of 'C'. Even functions considered >>> PUREstrong by the frontend may update an internal state, so the rules >>> just >>> don't apply. Except for maybe global functions... In any case, the >>> only >>> benefit you can reap from 'D pure' functions are that they are more >>> likely >>> to be const-folded / inlined. >>> >>> >> 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... >> > > Iain, are you sure about that? (No offense, but you have been wrong about > what GCC can/can't do in the past. :P) Could you maybe elaborate a bit and > present a counterexample? It might also be a question of how the »as-if« > rule is really defined for pure function calls. > > In any case, if the source is available, the LLVM optimizer is usually > very good at figuring out »pure for reals« (inferring the LLVM 'readnone' > attribute). Obviously, this doesn't help you when you are doing separate > compilation, though. > > David >
Sure about what? I don't even know what you are talking about. :o) <sic> -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
