[fpc-devel] Defer keyword

[Ryan Joseph]

> On May 6, 2021, at 11:40 PM, Sven Barth <pascaldragon at googlemail.com> wrote:
> 
> There is no "finalization" section. It's really just an implicit try ... finally block that the compiler inserts. Look for "cs_implicit_exceptions" and "pi_needs_implicit_finally" if you want to learn more.

Does that mean if you disable implicit exceptions then ALL ref counted types leak memory? I could swear there was some post-routine code did all the cleanup stuff and called finalization* on different types. That's how record operators worked I thought and so i thought a defer keyword could simply hook into that system.


>> Either way looking at the programming language landscape the better way forward seems to be some opt-in ARC for TObject but I don't know if the compiler team is receptive to that (Sven made some attempt years ago but abandoned it). it's kind of frustrating that we have ref counted types but that isn't extended to classes. Hopefully that's something we can tackle one of these days...
> The problem is that the whole class tree needs to support it for it to work correctly even if it's not the whole hierarchy that has as it enabled. That means at least one additional field inside TObject that a) controls that behavior and b) contains the reference count. This means that *all* class instances increase by a LongInt. This might not sound like much, but FPC also allows to work on smaller systems (and I don't mean the really small embedded ones as those don't have TObject enabled anyway) and there an additional LongInt for each instance might be critical.

That can never be an option to blow up TObject. I figured there could be something like a $M+ switch that would compile a class with ref counting. Then in the RTTI units we would simply have an entry for this new class type which had initialize/finalize/addref etc... functions. I saw this for record operators and dynamic arrays so I thought the system could be extended to classes.

> 
> If the reference count feature is optional (in addition to the above) then an open question is what would happen if such a reference counted instance is assigned to a non-reference counted one. This would need to take into account all ways such an instance or type can be used including TClass.

That doesn't sound like a problem to me but I haven't thought about it deeply. If it was confusing there could be a new var section to denote ARC objects:

var
  someClass: TMyObject;
retained
  someClass: TMyObject;
begin
end;

{$RETAINED+}
type
  TMyObject = class
    private
      someClass: TMyObject;
    public retained
      someClass: TMyObject;
      otherClass:  TObject; // this would give an error because class is not compiled for ARC
  end;
{$RETAINED-}


Regards,
	Ryan Joseph