Uh... destructors?

[bearophile]

Steven Schveighoffer:

> cast voids all warranties ;)

OK. But that idea is unchanged if you remove the cast and return an int* from that function.


> Memory allocation has to be allowed inside pure functions.  Otherwise,  
> pure functions are too strict and limited.

I agree. But there are different ways to allocate memory, and those differences are important.


> Allowing malloc is somewhat exceptional because you then must allow free.  
> But I see no reason (yet) to disallow free.  If free cannot be pure, then  
> malloc cannot be pure.

I suggest to disallow both malloc/calloc and free inside pure functions, because what malloc returns a pointer, that is a value, that is not deterministic, it changes across different calls to malloc.


> Note, the 'hole' you refer to is not a bad thing.

It's a bad thing that will cause troubles to both D programmers and D compiler writers :-)


> A weakly pure function  
> allows one to modularize pure functions, whereas prior to this, things  
> like sort could not be pure functions, and therefore could not be used  
> inside pure functions.  I think the hole allows pure functions to be  
> actually usable and easy whereas before they were much too obscure to be  
> useful in much code.

I think this is unrelated to the hole I was talking about.


> All that is required is to disallow casting.

Disallowing casting is not enough here.

I have written two more posts after that, but you may have missed them because I have broken the tread:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=130426

Some examples:

class Foo {
  int x;
  bool opEquals(Foo o) { return x == o.x; }
}
pure Foo bar() {
  return new Foo; // OK
}
void main() {
  Foo f1 = bar(); // OK
  Foo f2 = new Foo;
  f1.x = 10; // OK
  assert(f1 != f2); // OK
  f1 = f2; // OK
  assert(f1 is f2); // no  
}

Here bar() allocated memory and it's pure, this is OK. f1 is mutable. You are allowed to call opEquals. You are allowed to overwrite the reference f1. But you aren't allowed to read the reference f1, because this breaks the referential transparency of the results of pure functions.

The idea is a subtype of pointers/references, that at compile-time doesn't allow to read the value of the pointer/reference itself. I think this is able to patch the hole I was talking about (a cast is able to punch a hole again in this, of course).

Bye,
bearophile