On Wed, 23 Feb 2011 11:45:48 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 2/23/11 9:57 AM, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 10:46:43 -0500, Andrei Alexandrescu
<seewebsiteforem...@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
