GC-proof resource classes

[cym13 via Digitalmars-d]

On Saturday, 29 August 2015 at 22:50:44 UTC, Timon Gehr wrote:
> If it is no more than a normal method:
> - Why have special syntax for it?
> - Why should Object have it?

I see it a bit like popFront() and other range methods that are 
normal methods but take part in common process so their name was 
standardized and they are usually used through a special syntax. 
I have no answer for the Object comment, I don't see why it 
should have it if it doesn't do anything.

> If there is a destructor, this (usually) means that explicit 
> destruction is needed.
>
> Again, note that if I have
>
> import std.collection: Array;
> class C{ Array arr; ... }
>
> then now C implicitly has a destructor (that does nothing but 
> call arr's destructor which may in turn free memory on the C 
> heap).
>
> Constructor and destructor are supposed to frame the lifetime 
> of an instance. Destructors are in the language so that the 
> language can help with enforcing this. If there's a built-in 
> and expected way to violate this property, the syntactic 
> similarity of constructors and destructors is misleading, and 
> the features are less useful.

> Memory is a resource, and not all memory is allocated by the 
> GC. (c.f. 
> http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html)

It isn't quite the same kind of resource as, say, a File handle 
that would cause more problem if not handed closed in time. 
Letting the GC collect when it estimates that memory is low is 
often more than good enough. Also, whoever allocates/opens a 
resource is the one that should be freeing/closing it. That goes 
for memory as well.

> I assume this means allow 'new Class()' even if Class has a 
> destructor.

It means allow this class to be managed by the GC


> Why is it sensible to have the same syntax for allocation if
> deallocation/destruction needs to be handled differently?

Because memory management is the same here, internal resource 
management isn't

> I.e. leak memory.

or being incorrectly GC-ed, that seems more dangerous to me... 
Well it shouldn't happen anyway so crashing should actually be ok.

> Simple classes get an additional hidden field. Even the monitor 
> field is too much.

They're using the GC and you're worrying about 1 bit of overhead? 
Ok, not having it would be better but still...

> This does not make a lot of sense. If there is no live 
> reference to a class managing a resource and it would then need 
> to "fear" collection, this means that the resource has been 
> leaked.
Yeah, after thinking about it I agree with that.

---

Reading this made me think about why I'd want all classes to be 
managed by the GC. I think what I fear most is inconsistence in 
usage. Also, I always feel uneasy from this exodus away from the 
GC. Having a GC is great, I don't want to be forced to always 
manage memory by hand. Not being able to use a class (or struct, 
because I think it would apply too) because it has a destructor 
would be a disruptive hard to explain change.

The thing is I still think all resources aren't equal and having 
a mixed style when you do explicitely only what's necessary could 
prove powerful in D. I need to mature this idea though.

Letting that aside, I can't find a good reason for thoses objects 
to be used by the GC if their memory must be explicitely freed, I 
now think you're right about that. The more I think about it the 
more that solution makes sense to me... But it would be one hell 
of a breaking change so it probably won't happen... too bad 
because it is a better idea than not calling the destructor. Not 
calling it would produce leaks, calling ponce's leak detector 
would produce runtime errors... In that case having compile-time 
errors sounds better. And if one need it to fit in the garbage 
collector anyway but wants to free some resource he sure can 
afford a .close() method that would make it explicit instead of 
providing a destructor.

Yeah, that sounds right as it is.