DIP74 - where is at?

[Ola Fosheim Gr via Digitalmars-d]

On Sunday, 11 October 2015 at 22:33:44 UTC, Jonathan M Davis 
wrote:
> I don't want get into arguments about smart_ptr and unique_ptr. 
> It's completely irrelevant to my point.

Ok, but keep in mind that since unique_ptr is rc which max out at 
1 and therefore don't need extra support beyond having an owning 
pointer. So whatever is done for reasoning about rc also has to 
work for unique. If not thenD is doomed to fail, because nobody 
wants rc when unique is sufficient.

> weak_ptr doesn't work when the child is constructed by the 
> parent in the parent's constructor. The fact that the parent 
> does not have access to the smart pointer type that it's about 
> to be put into means that it cannot give that to the child. It 
> has to give it a normal pointer. And that means that you can't 
> make it so that all accesses to the parent object are via a 
> smart pointer. And in the case of D, that means that it doesn't 
> work to restrict all access to a class object to a wrapper 
> struct like RefCounted, and it becomes quite easy for a 
> reference to the class object to escape the wrapper struct.

Well, the wrapper approach is no good (is it part of dip74?) 
since it messes up alignment etc, so the refcount interface 
should be part of the parent object. The child can be given the 
Refcount interface from dip74, it won't use it for a weak 
reference until it dereference (borrow). A weak reference just 
delays destruction until the borrowing is completed.

So it works(?) if you dont allow dereferencing of the weak 
pointer in the constructor of the child.

> get used incorrectly. But part of the whole point of DIP 74 is 
> so that we can have @safe ref-counting in D.

Well, @safe in D is broken and should just be dropped in favour 
of something sane like real pointer analysis instead of piling up 
bad designs like dip25. You only have to run it for release... 
Who cares if it is slow?