Go 1.5

[ZombineDev via Digitalmars-d-announce]

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.