Dalija Prasnikar

Automatic invocation is the whole point of managed records. If they have constructors and destructors, you want them to run. Yes, you can do that manually, but then they would not be called managed records. If you don't want managed records, and you want to perform some initialization and finalization code manually, you can use plain record procedures. You don't need constructors and destructors in that case.

One of the problems with ARC enabled and having [unsafe] as default is that you cannot release object that has disabled reference counting. [unsafe] is only for marking additional references on objects whose memory is managed at some different place (reference). Of course, you can say that compiler would need some tweaking to allow destroying such objects, but it is very likely that at some point the whole construct would fall apart. I never gave mush thought to such "solution" because it seems pointless. Point is. ARC compiler was done right as far as its default behavior is concerned. There are few things around DisposeOf that could be polished, and some other minor bugs that are just bugs, not design flaws. ARC compiler fits the best into existing Delphi infrastructure and neatly fixes issues around object and interface references. Other solutions and workarounds will be poor substitutes and will not solve that duality problem. I wish I would be wrong on this one. I sincerely hope I am wrong and that there is another approach that will not be just a band aid, but full fledged solution.

But with normal var declarations you are forced to explicitly write the type for the variable. In this case, you can easily forget that you have to explicitly declare variable as interface and rely on type inference which will get it "wrong".

This is truly great and long missed feature. Truly great. But... I hate buts... there are things to watch out. Namely, type inference breaks reference counting. It is one of those don't mix objects and interfaces pitfalls. Should I say that this works perfectly on ARC compiler 🙂 If you have reference counted class, you cannot rely on type inference, you have to specify the interface type. // broken var Instance := TInterfacedObject.Create; // not broken var Instance: IInterface := TInterfacedObject.Create;

@Marco Cantu No matter how you turn it something is not quite right. I can certainly see why you made the choice you made. Both now, and back then when ARC was introduced. I hope that for the sake of present we (saying we because non-ARC is clearly what your customers want) didn't sacrifice the future.

@Sherlock If you get warnings, then this is kind of code that needs to be changed for ARC. But the change you do (depending on the actual code you need to change) will work across all compilers without warnings.

Just for the record, unless you have to change methods signatures - adding const param, and for some reason you need to keep old signature too, porting to ARC compiler itself does not require any IFDEFS. All needed changes are compatible with all compilers.

I found the report for Linux compiler that may have some impact on speed comparing to Windows (regardless of ARC) Linux x64 compiler produce very bloated code

1. Totally understandable. You cannot use ARC to its full potential and you are only paying the price. 2. I assume it was Linux vs Windows, It would be interesting to see how it compares with ARC removed. Comparing x86 with ARM is comparing apples with oranges - ARC or no ARC. AFAIK, LLVM backend has some influence on performance, too. There are some reports about inefficient code generation - something not ARC related. Performance mostly suffers because of existing code that is not written for ARC - unnecessary reference counting triggers are real performance killers. It is not fault of ARC per-se. 3. LOL - it is the same memory management model, (if you remove DisposeOf out of the picture) so pitfalls are exactly the same. Developing for ARC requires a bit different mindset.

I think most of EMBT customers will see that as a positive move. While I fully understand them, I am not so sure. More thoughts... ARC is dead, long live ARC