RCArray is unsafe

[via Digitalmars-d]

On Tuesday, 3 March 2015 at 08:04:25 UTC, Manu wrote:
> So, passing global x to some function; inc/dec x around the 
> function
> call that it's passed to...? Then the stack has its own 
> reference, and
> the global reference can go away safely.

Yes, the sane thing to do is to improve the general type system 
and general optimizer. The special casing D is going for will 
lead to no good. New non-trivial special case features just 
punches more holes in the type system. Which is the opposite of 
what is needed to bring D to a stable state.

By trivial I mean syntax sugar, which always is ok, but a type 
system should be general with no special casing in it.

What you need to do is to a way to implement smart pointers as 
non-ref-capable types, and the ability to do moves to transfer 
ownership up the call stack, and good general opimizations in the 
backends for it. AFAIK the current type system is too weak to 
enforce it. The type system also lacks head-const-ref, which 
often is needed for safe "manual optimization"?

The special casing effort is largely wasted because one cannot 
have efficient ARC without whole program/module optimization 
anyway. Swift ARC does better when optimizing larger units. With 
whole program optimization, stronger typing and smart inlining 
the RC performance issues can be reduced more efficiently.

It would be better to focus on ways to tighten the type system 
and how to utilize stronger typing for optimization of larger 
units (whole module/program). Special casing in the language 
makes optimization algorithms harder to write. Long term evil.