Uh... destructors?

bearophile bearophileHUGS at lycos.com
Wed Feb 23 12:28:32 PST 2011


Steven Schveighoffer:

> A pointer is not a value, it's a pointer.  int is a value.  You should  
> expect two calls to a pure function to return the same exact int.

I don't care of how you want to define what a pointer is. Definitions are labels for ideas, you are free to use a different label.


> Because memory allocation has side effects, you have to accept that it can  
> allow pure functions to not return exactly the same bits.

I have suggested a way to avoid most of problems caused by that fact.


> D is a language that allows pointers and comparison of pointers.  There  
> are plenty of languages that don't allow this (such as Java), one of those  
> might be better suited for your requirements.

Java too allows to compare the value of references (like the "is" D operator) so the type system idea I have suggested is applicable in Java too, if Java wants to add pure functions that allow allocations.


> I see zero value in disallowing comparing pointers in D.

I have not suggested to disallow comparing all pointers. I have suggested to disallow it only for pointers/references allocated inside a pure function, that are @transparent.


> What kinds of problems does pointer comparison cause?  I know of none.

If you compare pointers created in a pure function, you are breaking the most important constraint of pure functions. A pure function is deterministic. D pure function aren't deterministic, because the value of the memory pointers they return can be different across different calls. If you leave this hole in pure functions, then their purity is much less useful, you can't perform optimizations, you can't reason about code like you are able to do with pure functions.

Currently you are able to write functions like:

pure bool randomPure() {
    int[] a1 = new int[1];
    int[] a2 = new int[2];
    return a1.ptr > a2.ptr;
}

Is this function pure? It returns a pseudo-random boolean. You are free to define this function as pure, but this form of purity is much less strong than what people think of "pure".

With the type system change I have prosed it becomes:

pure bool randomPure() {
    @transparent int[] a1 = new int[1];
    @transparent int[] a2 = new int[2];
    return a1.ptr > a2.ptr; // compile-time error, their ptr are @transparent, so they can't be read
}


> Showing an  
> assert that two pointers are not equal is not evidence of an error, it's  
> evidence of incorrect expectations.

One of the main purposes of a type system is indeed to disallow programs based on incorrect expectations, to help programmers that may not always remeber what the incorrect expectations are :-)

Bye,
bearophile


More information about the Digitalmars-d mailing list