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?
