On Tuesday, April 8, 2025 9:07:45 AM MDT Guillaume Piolat via Digitalmars-d-learn wrote: > On Tuesday, 8 April 2025 at 14:00:56 UTC, Jonathan M Davis wrote: > > Of course, I'm also increasingly of the opinion that pure was a > > mistake in general, because it does almost nothing in practice > > but routinely doesn't work with straightforward code - and it's > > definitely one of those attributes which gets in way when code > > needs to be refactored > > > And you really need pureMalloc to be applicable, hovewer it's a > lie since the GC and malloc obviously have global state.
It at least makes more sense with the GC, because the freeing portion only occurs when it's guaranteed that the program no longer has access to the data, so the global state isn't really affected other than the bookkeeping that the GC does (which isn't normally accessed by the program and isn't pure if it is) or whether there's going to be memory available to allocate when new is called next (which doesn't really matter for the global state either, since faling to allocate memory is an Error, killing the program). On the other hand, pureFree has no such guarantee, since it's up to the programmer to make sure that it's not used when other references to the data still exist, and they can easily screw that up. But yeah, having memory allocations (from the GC or otherwise) work with pure code is on some level a lie about global state. And it ultimately adds to the complication of what pure really means and what can be done based on it. - Jonathan M Davis
