On 08/30/2015 12:10 PM, rsw0x wrote:
On Saturday, 29 August 2015 at 23:08:45 UTC, Timon Gehr wrote:
On 08/29/2015 04:45 PM, rsw0x wrote:
On Saturday, 29 August 2015 at 14:32:27 UTC, Timon Gehr wrote:
On 08/29/2015 04:20 PM, cym13 wrote:
On Saturday, 29 August 2015 at 14:17:10 UTC, rsw0x wrote:
[...]
After reading all that, I too am convinced that the GC shouldn't call
the destructor.
But then classes with destructors shouldn't be allowed to be allocated
on the GC heap in the first place, which is a PITA as well. (Note that
classes/arrays can have destructors because some component structs
have them; structs generally assume that their destructors will be
called.)
make classes with destructors(and structs allocated via new) have RC
semantics.
RC is an especially eager form of GC, that does not deal with cycles
by default. Why does it help?
The problem is that there's no guarantee the destructor will run with
the GC,
This is something the GC can in principle guarantee though, and it might
be good enough to deallocate memory.
no guarantee what thread it will run on, and no guarantee on
when it will run. RC guarantees all three of these
Those are good points, but why do this implicitly with the same
allocation syntax?
outside of cycles.
One might not have no cycles. Each reference counted reference has a
destructor. I.e. as soon as some class in an object graph has a
destructor, a lot of them do. I think it wouldn't necessarily be great
language design to have memory leaks caused by e.g. adding
std.container.Array to some class.
