[fpc-devel] Defer keyword

[Sven Barth]

Am 07.05.2021 um 00:32 schrieb Ryan Joseph via fpc-devel:
>
>> On May 6, 2021, at 4:26 PM, J. Gareth Moreton via fpc-devel <fpc-devel at lists.freepascal.org> wrote:
>>
>> There is a performance penalty when using them, which one reason why the compiler sources don't use them.  There's probably other reasons too.  There might be some speed-up potential where standard Exit calls are concerned, but I'm not sure.
> I just did a search and I did indeed see a few try..finally blocks but not many. As I understand it there is a "finalization" section of each procedure which is used for ref counted objects so I assumed the statement was merely moved to that location but I guess there's some concerns over exceptions.
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.
> 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.

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.

If the reference count would be enabled by default for *all* instance 
(like Delphi did in its platform compilers but which they abandoned now) 
then you'd have a huge backwards compatibility problem, because there 
definitely are cycles out there and thus this option would be an 
absolute no-no.

In my opinion the better solution is to continue the road that Maciej 
started and to implement that "default field" concept together with 
operator hoistening so that records with management operators can be 
used as containers. This is essentially the way it's done in C++ as well 
(e.g. we use that extensively at work), but it needs some questions 
solved for the default field functionality. This way the functionality 
is definitely optional and can be controlled per-instance instead of 
per-type. What it wouldn't solve however would be the assignment 
problems ("wrapped" to non-"wrapped" instance) though that could be 
probably be more or less solved by only allowing an explicit conversion 
to the non-"wrapped" instance.

Regards,
Sven