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.

On 1/15/22 13:02, Elronnd wrote:
> I will add: pure does not mean @safe.  The following program prints 17 on my computer with a recent dmd, for instance:
> 
> pure int f(int *x) {
>      return x[1];
> }
> int main() {
>      import std.stdio;
>      int x, y = 17;
>      writeln(f(&x));
>      return y;
> }

About this, this is fine. `pure` has a meaning. In @system code it is up to the programmer to ensure this meaning is respected, where the language can provide some assistance with sane defaults. But in @safe code, it's on the language, with some assistance of @trusted assumptions.