Go 1.5

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Tuesday, 22 September 2015 at 09:01:07 UTC, Chris wrote:
> But that's very annoying to work with and more pain than gain.

I don't know... unique_ptr in C++ is quite ok for managing 
resources, but it does not track "borrowed pointers". But as I 
point out one can:

1. do it in runtime in debug builds (have a pointer back to the 
owning pointer and "assert(*this.owner==this.ptr)" at every 
dereference).

2. one can build a prover that does a fair job out of proving 
that the owner lives longer than any pointer copied from the 
owner.

The caveat is that 2 might either require explicit annotations 
and/or take a long time, but maybe it is ok that it takes a long 
time if you only do pointer sanitisation (2) once in a while and 
use the assert method (1) during the daily development?

> In my initial post I was thinking of a runtime solution where 
> the object knows it's own life cycle, or at least knows when 
> its own death is nigh and destroys itself. I don't know if this 
> is possible at all, I simply borrowed this idea from biology. 
> We don't have GC in our bodies, cells know when it's time for 
> them to go.

Yes, that would be C++ shared_ptr and weak_ptr. Then you have to 
explicitly break all cycles in the graph with weak_ptr. All 
pointers pointing backwards in the three of shared_ptrs have to 
be weak_ptrs.

Kind of expensive since you need two objects for every object. 
When all shared pointers are dead you free the object, but you 
need a reference object to reference count weak_ptrs.

IIRC (I don't use shared_ptrs much).