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
