Escaping the Tyranny of the GC: std.rcstring, first blood

[Andrei Alexandrescu via Digitalmars-d]

On 9/28/14, 3:40 AM, Dmitry Olshansky wrote:
> 28-Sep-2014 00:16, Andrei Alexandrescu пишет:
> The key point is that the change is small, that's why (maybe) it's hard
> to grasp.

I think I get it now. It has a huge overlap with stuff that we already 
have. That doesn't bode very well!

> The whole thing is a bit of lowering and a "hint" to the
> compiler. It reuses the same mechanism that structs already have.
>
> Okay a few examples of lowering to get things going:
>
> http://dpaste.dzfl.pl/3722d9d70937
>
> (note I think there could be better lowerings and simpler set of
> primitives to bootstrap ARC-ed type)
>
> Now why would we need this trivial lowering?
>
> Typical postblit can be anything unless the compiler has full source
> code, dtor can be anything as well.
>
> With opInc/opDec compiler generates postblit/dtor on his own, in doing
> so it decorates user-defined dtor that actually clears resources.
>
> What being in control gives to the compiler:
>
> 1. Compiler always has the source of generated parts, so they can be
> inlined (and should be)

That's a given if the body of ctor/postblit/dtor is available. I don't 
see this as an important distinction.

> 2. Can do typical algebra optimization on opInc/opDec, no matter what's
> inside opInc and opDec (this is a contract between programmer and
> compiler).
>       e.g opInc(10) followed by OpDec(1) is opInc(9)

That typical algebra optimization is already doable post inlining 
without a language feature. Compilers know integer arithmetic.

> 3. Also opInc and opDec do not alter object in any capacity, nor are
> they affected by any method calls on this object (another contract)

....?

> 4. 1 + 2 = win, as by inlining postblits/dtors we expose opInc/opDecs to
> the optimizer pass which the would fold them using basic algebra
> optimizations.

I don't think this is a feature worth adding.



Andrei