Uh... destructors?

[Andrei Alexandrescu]

On 2/23/11 10:52 AM, Steven Schveighoffer wrote:
> 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.

Yah, that's why safety and purity go hand in hand with 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

Because a pure unsafe function is useless.


Andrei