Uh... destructors?

[Bruno Medeiros]

On 23/02/2011 17:47, Steven Schveighoffer wrote:
> On Wed, 23 Feb 2011 12:28:33 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 2/23/11 11:16 AM, Steven Schveighoffer wrote:
>
>>> Just because a function is not marked @safe does not mean it is unsafe.
>>> It just means you can do things the compiler cannot verify are safe, but
>>> that you know are actually safe. I showed you earlier an example of a
>>> safe pure function that uses malloc and free.
>>>
>>> Programmers are allowed to make conceptually safe functions which are
>>> not marked as @safe, why not the same for pure functions?
>>>
>>> -Steve
>>
>> I understand that. My point is that allowing unsafe functions to be
>> pure dilutes pure to the point of uselessness.
>
> And that's not a point. It's an unsupported opinion.
>
> pure has nothing to do with safety, it has to do with optimization. Safe
> functions are no more optimizable than unsafe ones. Safety has to do
> with reducing memory bugs.
>
> The two concepts are orthogonal, I have not been convinced otherwise.
>
> -Steve

pure has something to do with @safety. (Also, it has more to do with 
than just optimization, it also affects code readability.)

In order to gain any benefit from calling pure functions (whether the 
benefit is programmer code readability or compiler optimization) it 
needs to be determined from the pure function's signature what is the 
transitively reachable mutable state that the function may access. 
Normally this state is whatever is transitively reachable from the 
parameters. However, if you allow *arbitrary* _pointer arithmetic_ you 
could legally manipulate any mutable data in your program from within 
the pure function. This would make the pure attribute useless because it 
would not offer any additional guarantees whatsoever over an unpure 
function. So such a rule is necessary such that, for example, the 
following function should not be allowed to be pure:

pure int func(int* ptr, int ix) {
   return (ptr + ix)++;
}

I'm not sure if this is what Andrei had in mind with regards to @safety.
It should be noted that none of this implies that free() should be 
disallowed in pure functions. And indeed I think that if malloc() is 
allowerd, free() can and should be allowed as well.


-- 
Bruno Medeiros - Software Engineer