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.
