Uh... destructors?

[Steven Schveighoffer]

On Wed, 23 Feb 2011 15:28:32 -0500, bearophile <bearophileHUGS at lycos.com>  
wrote:

> Steven Schveighoffer:
>
>> 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.

That's not what your example showed.  It showed comparing two allocated  
pointers *outside* a pure function, and expected them to be equal.  I see  
that as disallowing all pointer comparisons.

>> 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;
> }

This is the first real example you have made that shows a problem!  It  
uses all valid constructs within pure functions (without casts), and by  
current rules could be considered strong-pure, however, it violates the  
rule of pure that the same parameters should result in the same answer.

> 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".

I would not define the function as pure.  The questions to answer are:

1. Can the compiler detect valid reference comparisons without annotation?
2. Is this going to be a common problem?

At first glance, I'd say the answer to number 2 is no.  Most people are  
not going to use the randomness of the memory allocator to subvert  
purity.  It's unlikely that you accidentally write code like that.

The answer to number 1, I don't know.  I don't think the compiler can  
determine the origin of allocated memory without annotation.

>
> 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
> }

I can see now the value in this.  I just wonder if it would be worth it.   
Seems like such a rare bug to create a whole new type constructor.

It also has some unpleasant effects.  For example, the object equality  
operator does this:

bool opEquals(Object o1, Object o2)
{
   if(o1 is o2)
     return true;
   ...
}

So this optimization would be unavailable inside pure functions, no?  Or  
require a dangerous cast?

Would it be enough to just require this type of restriction in pure @safe  
functions?

I feel that a new type of reference is likely overkill for this issue.

>> 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 :-)

My point in the above statement is that when you say:

auto a = new int[1];
auto b = new int[1];
assert(a.ptr == b.ptr);

is not evidence of an error :)  This is what you did previously.

-Steve