DIP74 - where is at?

[Tobias Müller via Digitalmars-d]

Manu via Digitalmars-d <digitalmars-d at puremagic.com> wrote: 
> Nothing here explains to me how it is that the compiler can do without
> RC primitives that the compiler knows it is allowed to
> optimise/schedule as it likes?
> How does it look in rust that it is able to optimise calls to inc/dec
> primitives?
> 
> You also make the points that I expect to bank on in D; we are
> thread-local by default (big advantage!), nothrow is pervasive (big
> advantage!), but the language still doesn't know the primitives that
> it can use to optimise.
> 
> The ownership proposal solving the problem isn't entirely correct.
> Sure, borrowed pointers imply RC elision, and it's particularly useful
> for writing API's that are allocation/ownership agnostic, but it
> doesn't solve the problem as you suggest. Once a pointer is borrowed,
> it can't be assigned to another RC pointer anymore. If you must use
> borrowing to implement RC elision across calls, then you lose the
> ability to give someone else a reference down the call-tree.
> Passing an RC object proper to a function also elides RC fiddling, but
> the compiler can't distinguish between RC fiddling and copying logic
> unless the RC primitives are explicit. I find that this is a very
> common case.

The key is, that RC in Rust is a move-by-default type. That means if you
are passing RCs around, you are actually passing ownership.
Only if you explicitly call 'clone', ownership is split up.
That means in the default case, no inc/dec is necessary.

Even more important, RC isn't used very often.
True shared ownership is actually quite rare. References (borrowed
pointers) and 'Box'es (unique pointers) are much more common.
shared_ptr is much overused in C++ IMO.

Tobi