D Language Foundation March 2023 Monthly Meeting Summary

[Dukc]

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.