RCArray is unsafe

[Paulo Pinto via Digitalmars-d]

On Tuesday, 3 March 2015 at 08:59:08 UTC, Ola Fosheim Grøstad 
wrote:
> 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.

You just reminded me of ParaSail. Here is the latest version of 
their pointer free programming paper.

https://drive.google.com/file/d/0B6Vq5QaY4U7ubm5qVkFpMEtmN2s/view?pli=1


--
Paulo