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

[Timon Gehr]

On 1/15/22 16:44, Paul Backus wrote:
> 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:
> ...

Sorry, it's just not a fair reading of that paragraph to claim that it 
is "explicitly allowed" or that it "just" says the result is 
implementation-defined. Clearly UB is terrible, so this is the best 
solution, particularly if you don't want to explain what "equivalent" means.

>> **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.)

*currently not required*.

This is one of those instances where the specification was changed to 
document undesirable behavior in the meantime before it is fixed in the 
language. It's not something that DIPs should rely on as a foundation.