Den Leak bei rekursiven Closures bekämpfen

[Der schöne Günther]

Zum Abend noch etwas eher Esoterisches:

Ein schlauer Kerl hatte hier nie die Speicherleck-Prüfung an. Ich schalte sie ein und
sehe dass dieses Konstrukt hier jedes mal eine TPrinter -Instanz und eine myClosure -Methode leaked. Letztere ist rekursiv und erhöht somit ihren eigenen Referenzzähler. Sie selbst hat aber natürlich auch eine Referenz auf den IPrinter weshalb dieser ebenfalls nie tot geht.

Zumindest vermute ich das, denn ich kenne keinen Weg im Debugger die Closure oder von dieser gecapturte Variablen zu untersuchen.
Dafür spricht auch wenn ich, wohl durch die Rekursion, den Referenzzähler der anonymen Methode von Hand um eins verringere- Das ist die letzte (auskommentierte) Zeile.

Delphi-Quellcode:

type
   IPrinter = interface
      procedure write(const value: Integer);
   end;

   TPrinter = class(TInterfacedObject, IPrinter)
      public procedure write(const value: Integer);
   end;

procedure p();
var
   myClosure: TProc;
   myCounter: Integer;
   myPrinter: IPrinter;
begin
   myCounter := 10;
   myPrinter := TPrinter.Create();

   myClosure :=
      procedure()
      begin
         myPrinter.write(myCounter);
         Dec(myCounter);
         if (myCounter > 0) then myClosure();
      end;
   myClosure();

   //IInterface( Pointer(@myClosure)^ )._Release();
end;

Meine Frage: Kann man das so machen? Sollte der Compiler das eines Tages ändern und den Referenzzähler bei Rekursion nicht erhöhen fliegt mir das ja wohl zur Laufzeit um die Ohren.

Das Beispiel ist natürlich stark simplifiziert und wirkt wahrscheinlich übertrieben aufwändig. Und ja, das bekommt man auch ganz klassisch ohne anonyme Methoden hin: Das ist jetzt meine Übergangslösung