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

[Paul Backus]

On Saturday, 15 January 2022 at 10:40:29 UTC, Timon Gehr wrote:
>> 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.

The spec explicitly allows such non-deterministic results; it 
just says that the behavior of calling such a function is 
implementation-defined:

> **Implementation Defined:** An implementation may assume that a 
> strongly pure function that returns a result without mutable 
> indirections will have the same effect for all invocations with 
> equivalent arguments. It is allowed to memoize the result of 
> the function under the assumption that equivalent parameters 
> always produce equivalent results. *A strongly pure function 
> may still have behavior inconsistent with memoization by e.g. 
> using casts or by changing behavior depending on the address of 
> its parameters.* An implementation is currently not required to 
> enforce validity of memoization in all cases.

(From https://dlang.org/spec/function.html#pure-functions. 
Emphasis added.)