On Friday, September 12, 2025 3:48:49 AM Mountain Daylight Time IchorDev via Digitalmars-d-learn wrote:
> Recently I wanted to write a pure function that returns an unpredictable number, so I decided to use RDTSC (and any equivalent instruction for other CPU architectures) to do this, since the compiler allows RDTSC to be marked as `pure`. However, in the end I discarded this idea because I figured that a `pure` function should never return a different value with the same input; and doing so would surely break any applicable memoisation. Inline assembly isn't checked by the compiler, so I was essentially doing the same thing as misusing `@trusted`…
>
> Or so I thought. Today I remembered that `pureMalloc` exists, which surely doesn't follow these rules and would definitely not work when memoised. So how come it's still allowed to be `pure` just by resetting ERRNO? It can return a different value with the same input, so does that mean that using RDTSC is also `pure`?

pureMalloc is one of those functions which was probably a mistake precisely because it's so easy to not take into account an assumption that the compiler is going to make based on pure. As it is, we've had bugs (and still have bugs) where some new behavior was added based on pure where it didn't take into account other assumptions already made by the compiler, resulting in the compiler doing the wrong thing in some cases (e.g. implicitly converting a return type to immutable, because the compiler incorrectly decided that it was not possible for the return value to have come from one of the function's arguments, thereby resulting in immutable values being mutated by mutable references to the data).

Honestly, I would strongly argue that unless you absolutely _need_ something to be pure, you should not mess with pure - _especially_ if it involves any situation where you have to decide whether an extern(C) function can be treated as pure instead of the compiler figuring it out. There are just too many factors to take into account with regards to what the compiler will or won't do in order to correctly determine whether it's going to work to treat the function as pure.

And even when you're completely relying on the compiler to determine pure, it's too easy for there to be subtle bugs such that the main reason that there aren't more bugs is likely that the compiler rarely actually does any optimizations based on pure - which also means that you rarely actually get any benefit from pure anyway. It's really only of value when you absolutely must be certain that no mutable, global state is being accessed (e.g. because you're doing something threading-related where it would matter). In practice, such concerns are really a non-issue for the vast majority of code, and using pure just limits the ability to refactor the code later (especially if it's part of a public API) - and of course, if you're adding pure extern(C) functions into the mix, then that's adding an additional layer of risk.

Either way, aside from issues related to memory, if you have a function which isn't guaranteed to return exactly the same value every single time that it's called with the same arguments, you shouldn't mark it as pure. Obviously, for extern(D) functions, that's supposed to be caught for you, but with extern(C), you shouldn't be using pure if you can't guarantee the same result every time that the same arguments are passed.

Memory gets weird on top of that because of the desire to use the GC with pure functions and the argument that two objects with the same value are the same even though they're different places in memory (so whether they're really the same or not depends on what you're looking to guarantee). But even when a pure function returns a newly allocated object, every time that that function is called with the same arguments, the resulting object needs have the same value as any of the other calls. So, while the objects may not be the same objects in memory, they need to have the same value.

pureMalloc was added because of the desire to do the same with malloc-ed memory, but IMHO, it was a very questionable choice, and as it is, there was a ton of arguing over it before it got merged precisely because of how tricky it is to be absolutely sure that it's going to do the right thing. Personally, I don't think that it should have been merged, and it would not surprise me in the least if the compiler did the wrong thing with pureMalloc some of the time.

However, if you have a function which is going to return an unpredictable number, then that's fundamentally not pure, because that means that it's not going to give the same result every time it's given the same arguments. Newly allocated memory gets a pass based on the argument that the result pointed to by the memory has the same value even if the pointer or reference differs, so in principle, it's the same value. However, that logic does not at all apply to a function that returns an unpredictable number.

- Jonathan M Davis