On Tuesday, January 17, 2012 23:40:35 Timon Gehr wrote:
> I think he is interested in the state of implementation of specific compiler _optimisations_ that make use of function purity in order to prove their correctness. IIRC ldc has CSE for pure functions, but I don't know exactly.

I have no idea what currently gets optimized by the compiler with regards to pure except for the fact that the function must be strongly pure and that optimizations only ever occur in a single statement (maybe even only in a single expression). That's a compiler implementation issue that I don't generally worry about. I'd _like_ it to optimize a lot, but that could easily vary as the implementation changes even after the language has been fully implemented.

Now, if you want to test it, aside from looking at the assembly generated by the compiler, you could use debug{} blocks with print statements in them, since you can put impure code in debug{} blocks for debugging purposes. So, with something like

auto pureFunc(immutable Type arg)
{
 debug { writefln("%s(%s): pureFunc called", __FILE__, __LINE__); }
 //... code
}

it becomes easy to see how well optimized out a pure functions' calls are.

- Jonathan M Davis

H. S. Teoh:

> But since this is apparently not yet implemented, just what *is* implemented currently when you specify 'pure'?  Common subexpression factorization? Hoisting? Not (yet) memoization, apparently.

Common subexpression factorization for strongly pure functions that return integral values.

Bye,
bearophile