Discussion Thread: DIP 1042--ProtoObject--Community Review Round 1

[Timon Gehr]

On 15.01.22 11:20, Elronnd wrote:
> On Saturday, 15 January 2022 at 10:15:16 UTC, Timon Gehr wrote:
>> The issue is not that addresses might change, it's that they depend on 
>> global state. Therefore, e.g., iteration order for an associative 
>> array will depend on global state too. It's just not `pure`.
> 
> It seems to me that any data passed from an impure function to a pure 
> one will depend on global state.

Not even true, but not getting into that. In any case, by passing it, 
you turn it into local state, that's why the qualifier "global" was 
there in the first place.

The point is that a pure function's result should _only_ depend on 
parameters. `pure` functions are functions that can't turn global state 
into local state.

> And d has no problem with pure 
> functions doing things to pointers that are passed to them anyway.

It makes absolutely no sense that a @safe pure function can cast an int* 
to size_t. It violates the spec of pure functions, because pure 
functions can create new int* with addresses that depend on global 
state, so if they can in turn create integers from those, that will 
produce non-deterministic results.

> So the current state seems fine (or, at least, fully consistent).

You mean fully consistent in its inconsistency? "If it's broken, don't 
fix it, embrace it"? A qualifier that does not exist is much better than 
a qualifier that does not mean anything. Why are people so obsessed with 
slapping qualifiers on functions that do not satisfy the restrictions 
which that qualifier is meant to guarantee? I will never understand, and 
I think neither should you.