Memory allocation purity

[Steven Schveighoffer via Digitalmars-d]

On Thu, 15 May 2014 10:42:00 -0400, David Nadlinger <code at klickverbot.at>  
wrote:

> On Thursday, 15 May 2014 at 13:42:58 UTC, Steven Schveighoffer wrote:
>> On Thu, 15 May 2014 09:24:54 -0400, Ola Fosheim Grøstad  
>> <ola.fosheim.grostad+dlang at gmail.com> wrote:
>>> That's the wrong attitude to take when it comes to the compiler and  
>>> runtime.
>>
>> There are always ways around the guarantees. This one isn't as  
>> detectable, since there is no "red-flag" cast or attribute. But I see  
>> no utility in such code.
>
> I have to agree with Ola here. If you write a piece of pure, @safe code,  
> there should be no way for compiler optimizations to make your code  
> behave differently.

In general, I would say any code that performs differently after  
optimization is not preferable. But in this case, you have ignored the  
rules, and the result is not exactly incorrect or unsafe. In fact, you  
can't really argue that it's invalid (randomBit could legitimately always  
return true or false, even in a non-optimized program).

The question here is, can we come up with a static rule that is effective,  
but not cripplingly prohibitive?

> This is not only because implicitly allowing unsafe code would be  
> against the design philosophy behind D, but also as attribute inference  
> might tag functions as pure without the programmer explicitly specifying  
> so.

So far, I haven't seen code that's unsafe only if optimized. Have an  
example?

>> In any case, the alternative is to have D pure functions avoid using  
>> pointers. It's as drastic as that.
>
> I'd suspect that it is enough to disallow using the content of pointers  
> explicitly, i.e. as a sequence of bytes instead of just a handle to an  
> object.

This means format("%x", ptr) isn't allowed to be pure?

What about calculating index offsets? Note that pointer math between two  
pointers on the same block of memory is perfectly legitimate.

I would expect that someone could be able to write a type equivalent to a  
slice, and it should be allowed to be pure.

-Steve