Is the implementation of Delphi interface reference counting future proof

Question

I have a helper class that will be in wide use across the application. The implementation relies on interface reference counting, the idea roughly is:

...
var
  lHelper: IMyHelper;
begin
  lHelper := TMyHelper.Create(some params);
  ...some code that doesn't have to access lHelper
end;

So the implementation relies on IMyHelper going out of scope at the end of the method, but not before.

So what am asking is, can I be certain that in some future Delphi compiler won't play smart and release the interface right after it's created if the variable is not accessed in rest of the method ?

Answer 1

IMHO you can be confident of that. The out-of-scope pattern will probably remain global to the instruction block of this method. This would be a breaking change.

See this comment from Barry Kelly (from Embarcadero):

As to your earlier comment, about explicit variables: in the hypothetical (and breaking change) case, where we optimized interface variable usage, we would likely not only break the described RAII-like functionality but also the explicit variable approach too; the values assigned to FooNotifier and BarNotifier are not used, so "in theory" they can be freed up sooner, and potentially even reuse the same storage.

But of course, destruction of the interface can have side-effects, and that's what's being relied upon for the effect in the post. Changing the language such that side-effects like these have visible changes is not something we do willingly.

So you can guess that Embarcadero won't introduce any backward compatibility change here. The benefit of re-using an interface memory won't be worth breaking compatibility and introducing side effects: saving a pointer (4 or 8 bytes) is not worth it nowadays, especially when the stack is already allocated, and aligned (x64 model uses more stack than x86).

Only if a Garbage Collector is introduced to the language (which I do not want from my personal point of view), objects life time may change. But in this case, life time may probably be longer.

In all cases, you can create your own code, to be sure that it will released at the end of the method:

var
  lHelper: IMyHelper;
begin
  lHelper := TMyHelper.Create(some params);
  try 
    ...some code that doesn't have to access lHelper
  finally
    lHelper := nil; // release the interface count by yourself
  end;
end;

In fact, this is the code already generated by the compiler. Writing this will be perfectly redundant, but it will ensure that compiler won't cheat on you.

When speaking of interfaces and reference counting, please take in account the potential issue of circular references in Delphi. See this great article (i.e. "Example 2-15") about the need of "weak pointers" for circular references of Interfaces.

Other languages (like Java or C#) use a garbage collector to resolve this. Objective C uses an explicit "zeroing weak pointers" mechanism to solve it - see this discussion or this SO answer for a potential implementation. Perhaps future version of Delphi may consider using an implementation similar to the ARC model introduced in Objective C. But I suspect there will be an explicit syntax to preserve compatibility with existing code.

Answer 2

The documentation says this (emphasis mine):

On the Win32 platform, interface references are typically managed through reference-counting, which depends on the _AddRef and _Release methods inherited from System/IInterface. Using the default implementation of reference counting, when an object is referenced only through interfaces, there is no need to destroy it manually; the object is automatically destroyed when the last reference to it goes out of scope.

The scope of a local variable is the method and so the current specification is that _Release will not be called until the method is complete.

There's never a promise that specifications will not be changed in the future but I think the likelihood of a change being made to this part of the language is vanishingly small.