D has a `pure` attribute for functions, and yes it is enforced. It's enforced even to the point where it becomes a PITA, but when you manage to make functions pure, you know it's solid.

One pain point with pure functions is you can't insert debug logging statements. D has a special case for that - purity for a statement isn't checked if it is prefixed with the `debug` keyword:

    pure int square(int x) {
        debug printf("called square\n");
        return x * x;
    }

which is very, very handy.

This seems a very pragmatic solution.

Isn't that erroneous, in the sense that printf() has side-effects, breaking the "pure" promise?

Indeed it does break the pure promise. But it's only for debugging builds.

The same "trick" is especially handy in a pure-by-design language like Haskell. There you have the `trace` function which prints to stdout while pretending not to. It's similarly useful, even if it may get called zero or many times. Is the same true of D's debug?

No, in D any statement prefixed with `debug` does not get its purity checked. `debug` prefixed code is enabled via a command line switch, otherwise it is excised.

I.e. it's for conditionally inserting debugging code where you don't care about purity, you just want to find the bug.

This means you can't re-order the computation, though, or memoize it—at least not the the extent it's possible without IO.

The use of the debug {} block in D is opt-in e.g. the compiler only includes those statements when given the debug flag

https://d.godbolt.org/z/Rwu4Cq (remove "-d-debug" to see)

Furthermore AFAIK things prefixed with debug don't get compiled into release binaries either.

I wonder does that mean you could also enforce freeing memory allocated by a pure function as well?

I'm not sure what you mean?

Allocators are often pure in D, they probably shouldn't be but that would mean allocating outside the function which would be ugly and probably buggy too

Obviously a pure function can allocate memory on the stack. I would think it could also allocate memory on the heap, iff it was guaranteed that the memory was freed before the function exits. Was thinking that would be something the compiler would do.

Forgive me I'm just a small brained firmware programmer.

So it seems that you are sort of talking about a function that is memoizable but not pure. Pure has no mutation of any global state. So hypothetically touching the heap means not pure - if somehow others can see it.

So where do we draw the line? Of course, no real computer implementation of any language is going to be able to generate fundamentally pure code because in the end they're going to be mutating memory (at the very least the program counter).

That's not a very useful distinction, and usually one talks about "purity" at a conceptual level. The language provides a layer of abstraction in which things can be considered pure (or not), even if the underlying implementation e.g. makes optimizations that require mutation. The language is just a guarantee that you can ignore these aspects of its implementation.

I think that is a good point at the end. Pure may be defined in regards to the language. So allocating memory in C may make a function unpure but something other languages may still be pure.

Rolling it over I think vaguely along the idea that marking a function as pure is a contract that tells the compiler that the function and it's call tree ultimately shouldn't modify external state.

A function that allocates memory isn't pure, except perhaps iff it frees that memory either itself or by compiler magic. Then perhaps it is.

They are a promise and that is precisely what makes them powerful. It gives GCC info it might not be able to derive, but you know to be true.

You can even promise a func is pure without even implementing it in the same translation unit! That produces lots of improvement. See these two godbolt links:

https://godbolt.org/z/v2zqJI

https://godbolt.org/z/kk3Q3T

> You can even promise a func is pure without even implementing it in the same translation unit!

Actually that's the main point, as if it's in the same TU, the compiler can probably figure out a function is pure.

often but not always, for example a function using asm() to access, say, some AES intrinsics is pure (const even) since the output only depends on input, but oftentimes compiler by itself will not declare a function with an asm() block pure or const

Well, fair point, but - compilers shouldn't be that lazy :-)