RCArray is unsafe

Paulo Pinto via Digitalmars-d digitalmars-d at puremagic.com
Tue Mar 3 11:50:45 PST 2015

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



More information about the Digitalmars-d mailing list