Uh... destructors?

[bearophile]

Steven Schveighoffer:

> That is allowed, and it's expected that a pure function can return  
> different references with identical calls.

A pointer and a "transparent reference" are two different things. That function returns a pointer, and a pointer is a value.
If you call a pure function with the same input you need to receive the same value. Otherwise it's not pure. If you mean something else, then you have redefined the meaning of "pure" so much that the word "pure" is the wrong one to use.


> pure functions are not necessarily @safe functions, you can access  
> pointers.

I know what I am currently able to do with pure functions in D. But here we are talking about what's the right/good way to design purity (or maybe we are even talking about what's the right way to modify D purity).

I presume you have understood what I have explained about transparent references.


> Pure functions are 100% about optimization.

Pure means first of all avoiding side effects. A pure function is not allowed to do some things, so both the programmer and the compiler are able to use such stronger constrains to perform some extra trasnformations normally not allowed on impure functions, and the resulting code is safer from certain kinds of bugs.


> An optimization should *never* be assumed.  That is, given  
> a pure function foo that returns a string, it should not be assumed that:
> 
> auto s = foo();
> auto s2 = foo();
> 
> is always factored into
> 
> auto s = foo();
> auto s2 = s;
> 
> It's an optimization, one which the compiler could or could not decide to  
> use.
> 
> However, it *should* be assumed that:
> 
> assert(s == s2);
> 
> That is, the values are the same.

I have suggested an extension of the type system that disallows statically code like:
assert(s.ptr == s2.ptr);

because this may break the transparent nature of references coming out of pure functions.


> What are your expectations for pure functions?

Allocating memory in a pure function is so useful that I expect D pure function to allow it. On the other hand I expect pure functions to behave deterministically, same input means same output. To solve this I have suggested di disallow reading the value of references/pointers coming out of pure functions.


> There is no such guarantee for weakly-pure functions.  There's not even  
> such a guarantee for strong-pure functions.

I know. This is something I'd like to add (well, I am not sure it's implementable, I am not sure it's a good idea, etc, so it's just an idea for now. And I don't think D will add it).


> To guarantee this would  
> require some sort of memoization, and require optimizations to be followed.

I think no memoization is needed, I think the only change needed is on the type system (so there are no effects on runtime. This type system just disallows some programs).

I may call them @transparent pointers/references, they are a supertype of normal ones:

class Foo() {}
pure @transparent(Foo) bar() {
  return new Foo();
}
Foo bar2() { // not pure
  return new Foo();
}
void main() {
  @transparent Foo f1 = bar(); // OK
  @transparent Foo f2 = bar2(); // OK
  Foo f3 = bar(); // not allowed, Foo is a subtype of @transparent(Foo)
}


On a @transparent Foo reference you are allowed to overwrite it, modify or use anything in the class itself, but you are statically allowed to use "is" operator on it, because it breaks its transparency (if you cast it to a pointer or not transparent, then you punch a hole in this type part of the type system).

Something similar is acceptable for struct pointers too, and arrays:

struct Spam() {}
@transparent Spam* bar3() {
  return new Spam();
}

struct Spam() {}
@transparent int[] bar4() {
  return new int[10];
}

Bye,
bearophile