• Frustrated (45/45) May 05 2014 I never got the real issue with destructors(I haven't seen the
• "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (12/25) May 06 2014 I don't see a need to distinguish between all possible ways of
• HaraldZealot (12/18) May 06 2014 And we come to some kind of Andrei's proposal to remove class

"Frustrated" <Who where.com> writes:

I never got the real issue with destructors(I haven't seen the 
issue explained, just a lot of talk about it being a problem and 
how to fix it) but I think doing away with them would be a very 
bad idea. Assuming the only/main issue is with the GC not 
guaranteeing to call them then that is really throwing out the 
baby with the bathwater.

Some of us do not want to be locked down by the GC. If you shape 
the D language around using the GC then you just our hole deeper 
and deeper. (We are trying to get out of this hole, remember?)


So, instead of removing destructors why not have multiple types? 
If the object is manually allocated then we can guarantee the 
destructor will be called when the object is free'ed.

But basically, since they would be different types of destructors 
there would be no confusion about when they would or wouldn't be 
called.

1. GC destructors - Never called when the object is managed by 
the GC. (or maybe one can flag certain ones to always be called 
and the GC will respect that)

2. Manual memory management destructors - Always called when the 
object is allocated by manually.

3. Others(ARC, etc) - Same principle.


So, while this could provide different behavior depending on how 
you use memory(not a great thing but possibly necessary), it at 
least provides the separation for a choice. (and it's a about 
choice, not about forcing people to use something that doesn't 
work for them)




It seems to me we have 4 basic lifetimes of an object:

1. Fixed/Physical Scope - The object lives and dies very quickly 
and is well defined.

2. UnFixed/Logical Scope - The scope is not well defined but 
something somewhere free's the object in a predictable way when 
it(the programmer) decides it should be free'ed).

3.  Auto Scope - A combination of the above where an object can 
live in both at the same time and automatically determines when 
it goes out of the the last scope. This is like ARC type of stuff.

4. Unknown/Non-Deterministic/Unpredictable -  There are no 
scopes. Objects lifetimes are completely handled by God(the GC). 
We don't have to worry about any of it. Unfortunately D's GC 
hasn't had it's `god mode` flag set.


1 and 2 essentially are old school manual memory management.


If we have object's lifetimes that exist in different ways then 
having different destructors for these possibilities seems 
logical. The problem may simply be that we are trying to fit one 
destructor to all the cases and it simply doesn't work that way.

Anyways... just food for thought.

"Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:

On Monday, 5 May 2014 at 18:08:22 UTC, Frustrated wrote:
 So, instead of removing destructors why not have multiple 
 types? If the object is manually allocated then we can 
 guarantee the destructor will be called when the object is 
 free'ed.

 But basically, since they would be different types of 
 destructors there would be no confusion about when they would 
 or wouldn't be called.

 1. GC destructors - Never called when the object is managed by 
 the GC. (or maybe one can flag certain ones to always be called 
 and the GC will respect that)

 2. Manual memory management destructors - Always called when 
 the object is allocated by manually.

 3. Others(ARC, etc) - Same principle.

I don't see a need to distinguish between all possible ways of 
memory management. The key distinction is whether it's reliable 
or not. RAII/scope and manual management are deterministic and 
reliable, tracing GC is not, and ARC only if cycles are 
disallowed.

Destructors of the first kind are usually called just destructors 
and are used for resource management, and the second kind are 
called finalizers. These are useful for implementing weak 
references, caching, and various other things where you don't 
require objects to be destroyed at a certain point in time, but 
still want to get notified when they are.

"HaraldZealot" <harald_zealot tut.by> writes:

 Destructors of the first kind are usually called just 
 destructors and are used for resource management, and the 
 second kind are called finalizers. These are useful for 
 implementing weak references, caching, and various other things 
 where you don't require objects to be destroyed at a certain 
 point in time, but still want to get notified when they are.

And we come to some kind of Andrei's proposal to remove class 
destructor. In my view problem lays not in the fact, that there 
are two world, but in how the beings from theses world must 
interacting. Now we have the fire and the water but we must 
invent the steam engine.

Possible steam engine can look like that:
The structures with destructor disallowed as member of classes, 
but compiler suggest in such case tip like that
class C
{
SomeKindOfSmartPointer!S p; // or better SomeKindOfMagic!S p;
}