This is particularly important and visible when using refcounted types. For such types, the (invisible) incrementing and decrementing of any reference count is omitted when const is used. Doing so often allows the compiler to omit invisible try/finally frames for these routines.This behaviour is by design

function tmt(const a: IT2): boolean;...tmt(T2.Create()) - do not operate with reference counter (I.e. destructor will be do not executed).

Delphi has the exact same problem. It is a gotcha in how 'const' bypasses reference counting. Neither compiler (Delphi or FreePascal) is smart enough to recognize when an interfaced object is constructed directly in a const parameter, which would require a local variable to hold the object so it gets refcounted and destructed correctly. People have complained about this issue in Delphi for years, and BorInCoDero has acknowledged it but refuses to fix it. Sad that it exists in FreePascal as well, especially if it is "by design" - it is broken design!

Yes, and that works in Delphi as well. Just note that the interface reference is not cleared when tmt() exits, like one would expect, but rather when the *calling* code exits! This is because the compiler is creating a hidden local variable that acts like any other variable, eg:

It's a known and undocumented bug that will not get fixed until it's fixed in Delphi (fpc follows Delphi to the letter including the bugs).Never use const with ref counted interfaces.

Oh? Explain the bug, plz.... Because there isn't any.... Some people mix classes with interfaces as was initially the case here, but that is programmer error.A const interface parameter needs to increase and decrease refcount inside a procedure or function body, that's not a bug.It needs to have a valid reference at all times.Furthermore: FPC behaves differently than Delphi regarding release moment inside a procedure or function body in this case. And that is implementation detail AND is documented AND usually does not matter.

Just curious: WHY do you think it is a bug? It isn't... Also not in other languages....that support COM interfaces....

I do not agree. I always use const for reference types. Moreover, I recommend doing this, precisely because of the optimality that is described in the documentation. But I do not recommend creating objects without binding, at which an error occurs.

Btw. const params for strings have a similar problem (code is Delphi, FPC doesn't support abstract methods yet):

Have the similar (identical) feature, not problem. It is true for every reference counted type by necessity: keeping a reference... The difference between passing by value and const is the implicit try/finally, not the refcount....

(2. on OSX FPC supports blocks already. That's basically similar to what you call "abstract methods", they are actually not abstract, but anonymous methods)