Uh... destructors?

[Steven Schveighoffer]

On Wed, 23 Feb 2011 11:45:48 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 2/23/11 9:57 AM, Steven Schveighoffer wrote:
>> On Wed, 23 Feb 2011 10:46:43 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> At a level it's clear to me that a function cannot be at the same time
>>> pure and unsafe. For example:
>>>
>>> pure void foo(int *x) { free(x); (*x)++; }
>>>
>>> This function essentially breaks any guarantee for the entire program,
>>> so it would be quite difficult to claim it's pure.
>>
>> I thought @safe was orthogonal to pure? If this isn't the case, then
>> yes, free must be disallowed. But then malloc must also be, and any
>> construct which manages its own memory via malloc/free.
>
> malloc can be reasonably made pure. It would be a mistake to see malloc  
> and free as two symmetrical parts of a whole. The truth of the matter is  
> that allocating is fine, deallocating is problematic.

So what happens to programs that just use malloc and don't use free?  I  
think you have to consider that if a pure function doesn't return its  
malloc'd memory, it will leak, and a leaking pure function is just as bad  
as an usafe one IMO.

D's malloc, however, does not require free to be callable since the memory  
will be cleaned up by the GC.

>
>>  From what I remember, pure functions:
>>
>> 1. cannot access shared or global non-immutable data
>> 2. cannot call non-pure functions
>>
>> I don't remember the definition that pure functions must also be @safe.
>
> Perhaps we should amend the definition.

Why?  We have both attributes, why not just require "@safe pure" if you  
want @safe pure functions?

-Steve