On Monday, 21 September 2015 at 10:25:05 UTC, Chris wrote:
On Monday, 21 September 2015 at 10:18:17 UTC, Ola Fosheim
Grøstad wrote:
On Monday, 21 September 2015 at 09:58:31 UTC, Chris wrote:
I sometimes wonder - and please forgive me my ignorance,
because I'm not a GC expert at all - if it would be possible
to create a system where the created objects know their own
life spans and destroy themselves, once they are no longer
used. Like the cells in our bodies.
Yes, this is the system Rust uses, but the compiler has to
prove the life spans at compile time. So how convenient that
is, is limited to the capabilities of the prover and for how
long you want to wait for the computation of the life times.
So I'm not completely nuts! Good to know. :) I wonder, if
something like this is feasible in D.
There's also a simple thing called smart pointers which do this
with RAII, copy and move semantics. Smart pointers manage the
lifetime of the object they point to automatically. You just need
to make sure that you access the object only through the smart
pointer, because if you get another reference (through other
means) that the smart pointer doesn't know about, the smart
pointer may free the object too early.
I prefer library-defined smart pointers than language magic,
because you can easily modify them to fit your needs. What D
needs is a way to enforce that the user can't get unmanaged
references to the underlying object managed by the smart pointer.
The killer way to implement this in D is to NOT add complexity in
the compiler (and to change the whole language to some imaginable
perfect correct memory management system), but to add away for
the library writers to write extensible CTFE checkers that
enforce the smart pointer invariants at compile-time.
