DIP74 - where is at?

[Jonathan M Davis via Digitalmars-d]

On Sunday, 11 October 2015 at 23:08:58 UTC, Manu wrote:
> Incidentally, I tried to use shared_ptr initially, but it took 
> about 20 minutes before I realised I had to pass an rc pointer 
> from a method... Since rc is a wrapper, like you said above, 
> you lose it as soon as you're within a method. I then had to 
> write an invasive rc implementation and hard create a new rc 
> instance from 'this', all over the place. Seriously, I don't 
> understand how anyone can say shared_ptr is a success. It's a 
> massive kludge, and it alone has me firmly convinced that rc is 
> weak, inconvenient, and highly complicated without language 
> support.

If you use shared_ptr, what typically happens is that you use 
shared_ptr everywhere and naked pointers pretty much disappear 
from your code. The main problem is when a type needs to return a 
pointer to itself, but in my own code, I've found that need to be 
rare (if anything, I'm more likely to pass an object out of its 
own member function by &, not by pointer). The primary 
counter-example is when a class that it owns needs to have access 
to it, but then in most cases, that class doesn't need to pass 
that pointer on to anyone else, and since it lives for as long as 
its parent does, it doesn't have to worry about ref-counting. I 
suppose that using & would work just as well in those cases, 
though I don't tend to use & much outside of passing into a 
function and returning out of it (generally when having a copy is 
okay but I want it to be possible to avoid it), because it's too 
easy to make inadvertent copies.

Having ref-counting built into the type does solve some of those 
problems, but it can cause others. I doubt that there was ever 
any chance that the C++ standards committee would have ever gone 
with built-in ref-counting though given how invasive that is in 
the class hierarchy and how it would not work very well with 
existing code. In our case, with classes, built-in ref-counting 
like DIP 74 proposes is probably better.

- Jonathan M Davis