Automatic object deletion

[Blestan]

nooo im completely on maciej side ... just wondering about the resistance...

[Thaddy]

That's guardianship... Just that...That's why FPC turned into such a high quality compiler... nothing more, nothing less....

[carl_caulkett]

Code: Pascal  [Select][+][-]

1. var
2.   List: TStringList;
3. begin
4.   List := Auto(TStringList.Create).Instance;
5.   // Do stuff with List...
6.   // No need to free anything.
7.   // Will automatically free contained object when interface goes out of scope. ie. at end of procedure/method.
8.   // Copes with exceptions - no need for try finally
9. end;
10.  

this code will not work in current FPC:

https://bugs.freepascal.org/view.php?id=26602
https://bugs.freepascal.org/view.php?id=30409

Thanks for confirming this. It's a good job I don't use this anymore!

[Thaddy]

Why? because I just showed you it is possible already (with some quirks) and in the near future even easier?

[hnb]

...
(I hope Maciej and devs agree that this is, just about, a proper summary)

nooo im completely on maciej side ... just wondering about the resistance...

thanks . Some resistance is sometimes good. It help to reflect (new ideas and roads) and help to keep humility, which is important in this kind of development. IMO a little lower resistance would be better
; )

[carl_caulkett]

Why? because I just showed you it is possible already (with some quirks) and in the near future even easier?

*Sigh*. When I said, "It's a good job I don't use this anymore!" I meant "it's a good job I don't use the code based on my IcaAutoFree/TcaAutoFree classes anymore".

[Thaddy]

*Sigh*. When I said, "It's a good job I don't use this anymore!" I meant "it's a good job I don't use the code based on my IcaAutoFree/TcaAutoFree classes anymore".

Thats' ok. I so overheated in this discussion I simply *know* you had to sigh after re-reading my own comments.,
But it was on topic. So I won't retract what I wrote, since it is still correct. Ok?

[carl_caulkett]

No problem!

Can you clarify what you wrote earlier. As I understand it Maciej is working on an Auto mechanism which will be ready in a few months. But will this feature be limited to Delphi mode? And on a more general level what are the advantages and disadvantages of Delphi mode vs Objfpc mode. I have always used Objfpc mode because that's the default, and it seems to work fine for me. Would I gain any advantage by using Delphi mode?

[Thaddy]

No problem!

Can you clarify what you wrote earlier. As I understand it Maciej is working on an Auto mechanism which will be ready in a few months.[ this is undefined. Time has no limits But will this feature be limited to Delphi mode? And on a more general level what are the advantages and disadvantages of Delphi mode vs Objfpc mode. I have always used Objfpc mode because that's the default, and it seems to work fine for me. Would I gain any advantage by using Delphi mode?

Apart from a slight edit in your remark:
Delphi mode?  Makes no difference. In OBJFPC mode type "specialize" (a lot) <grin>
FPC works on a per unit basis and the syntax you choose is based on what you prefer.... this is a concept that is amazing.... and not seen elsewhere on sourcecode level.
It is possible to use Delphi syntax in your own units (or><) without you ever knowing with what syntax the original code was written in a used unit.

So, if   when Maciej achieves what he wants it will be transparent. Like it is now.

[avra]

this is a concept that is amazing.... and not seen elsewhere on sourcecode level.

+1 

[carl_caulkett]

Why? because I just showed you it is possible already (with some quirks) and in the near future even easier?

Thaddy, I must apologise, I didn't realise that the example code you posted showed that Auto free *is* possible now, albeit with the double declaration. When I first saw the message, I didn't look closely enough at the code. In my defence, I had just woken up! I'm going to try it out now.

[carl_caulkett]

I already showed it works some time ago, Maciej... Ok, adapted example...:

Using Lazarus 1.8.0 RC3
macOS 10.12.5

I tried building a package with the unit, and when it tried to build the two lines:

Code: Pascal  [Select][+][-]

1.    
2.     class operator Implicit(AValue: T): Auto<T>;
3.     class operator Implicit(Smart: Auto<T>): T;
4.  

it fails with a couple of error messages which each say:
caauto.pas(27,48) Error: Impossible to overload assignment for equal types

Any ideas? Is this a typo? Should just one of those Implicit lines be in there?

[hnb]

it fails with a couple of error messages which each say:
caauto.pas(27,48) Error: Impossible to overload assignment for equal types

Any ideas? Is this a typo? Should just one of those Implicit lines be in there?

you need to use latest FPC trunk. Lazarus is shipped with latest stable version of FPC.

related bug report: https://bugs.freepascal.org/view.php?id=30534

fixed in rev. 35740

[carl_caulkett]

Thanks, Maciej. Presumably, if I were to build Lazarus using the latest FPC trunk, the IDE would not be so stable. Since I have a lot of code that I am involved in writing, at the moment, I think I will wait until a release version of Lazarus is released with these language changes included. I know it's a horrible question, but have you any idea when that might be? (When asked similar questions, I would always reply, "When it's ready"!)

[Thaddy]

Carl, there is always a risk that something only works in trunk. Or does not work in a release.
I am sorry if some features we discussed here are not ready or back-ported to an official release.
It is also a demonstration of the care  that is taken before anything is allowed in the Language.
This is not a library change, no, it is on the language level. (And my  example was merely a demonstration of about year ago, with "Auto" search/replaced today)