On Tuesday, 11 April 2023 at 21:53:50 UTC, Mike Parker wrote:
The language shouldn't support by default making a storage
allocator pure. It's doing its job, saying you can't do this
because you're changing state. So you have to fake it by doing
a dirty cast in there somewhere. The reason why D supports
system code is so you can do dirty things when you have to.
It's the same with `const`. D does not support logical const,
because logical const is not const. It's not enforceable.
That's a feature. If you want logical const, you have to do
something dirty to get it, and that's appropriate.
No, these are different.
`pure` only says the compiler is allowed to cache the result of a
function and reuse it for similar calls. You are allowed to do
debug logging, or return different results with subsequent calls
(by casting an impure function to `pure`), as long as you accept
that this results in unspecified behaviour. This means marking a
custom allocator `pure` is okay (the [pure factory
function](https://dlang.org/spec/function.html#pure-factory-functions) rule forbids the compiler from caching the memory address of the returned result).
On the other hand, mutating anything through a `const` reference
is not only unspecific behafiour, it is un*defined* behaviour.
The compiler may simply assume you don't do this, so if you do,
anything may happen. Any D program using `const` as "logical" is
excommunicated by the spec.
With `pure` hacks, there's more than one thing that may happen,
but the options are still limited. With `const` hacks, they are
not. The former are dirty hacks but legal, the latter are totally
illegal.
It they are intended to be the same, the spec needs changes.
