Rebooting the __metada/__mutable discussion

[Timon Gehr]

On 07.04.22 19:40, rikki cattermole wrote:
> 
> On 07/04/2022 8:51 PM, RazvanN wrote:
>> I think that the problem here is that we are conflating a high-level 
>> concept (purity) with low level operations (allocation/deallocation). 
>> The latter category is essentially not pure because it modifies 
>> operating system data structures, so I would say that we could view 
>> them as system code, not in the sense that they are unsafe (although 
>> they could be), but because they require OS assistance.
> 
> I've had to argue with myself on if memory mapping should be viewed as 
> pure or not. During development of my own allocators.
> 
> Ultimately the argument I came up with is that we have already defined 
> memory mapping in the form of new as being pure. I disagree that it 
> should be defined as such, but it has been.
> ...

That's just the wrong level of abstraction. Clearly creating new values 
should be pure, you can create arbitrary tree structures in basically 
all purely functional programming languages. It's usually the very core 
of how such code operates... The justification for `pure` in D is to be 
able to somewhat compete with such languages.

Whether allocation/memory mapping itself should be `pure` is debatable. 
It certainly can't be `pure` if allocation failure is not fatal or it 
returns uninitialized memory that can be accessed.

However, `new` (memory mapping + initialization + construction) is not 
setting any precedent for that, it's more high level.

> As such I have classified memory mapping as being a set of "deity" 
> functions. Things that modify the execution environment but not the 
> logic being executed therefore can be considered pure.

There is no issue with allocation plus construction as long as none of 
the allocator state can leak into the observable behavior. (E.g., 
peeking into the bits of pointers should be impure.) Deallocation needs 
to be treated specially in any case though.