Re: [fpc-devel] Defer keyword

2021-05-10 Thread Kostas Michalopoulos via fpc-devel
On 5/11/2021 4:09 AM, Ryan Joseph via fpc-devel wrote: On May 10, 2021, at 5:59 PM, Kostas Michalopoulos via fpc-devel wrote: You do not need any special language feature for that, you can simply do something like ReleaseLater(TObject.Create) yes but we can't get back the

Re: [fpc-devel] Defer keyword

2021-05-10 Thread Ryan Joseph via fpc-devel
> On May 10, 2021, at 5:59 PM, Kostas Michalopoulos via fpc-devel > wrote: > > You do not need any special language feature for that, you can simply do > something like > >ReleaseLater(TObject.Create) yes but we can't get back the reference. It's a small thing but making this possible

Re: [fpc-devel] Defer keyword

2021-05-10 Thread Kostas Michalopoulos via fpc-devel
On 5/8/2021 8:27 PM, Ryan Joseph via fpc-devel wrote: That was a bad example. It's for ANY class really. o := TObject.Create.AutoRelease; Then next event cycle the autorelease pool frees all the objects added to it. Very simple but effective however we can't do this in Pascal without a new

Re: [fpc-devel] Defer keyword

2021-05-08 Thread Ryan Joseph via fpc-devel
> On May 8, 2021, at 8:05 AM, Sven Barth wrote: > >> a := TArray.Create([1,2,3]).AutoRelease; >> >> We can't do this in Pascal because the AutoRelease functions return type is >> not compatible with the type of the caller. Could we add something like an >> "Any" return type to Pascal which

Re: [fpc-devel] Defer keyword

2021-05-08 Thread Sven Barth via fpc-devel
Am 07.05.2021 um 17:57 schrieb Ryan Joseph via fpc-devel: On May 7, 2021, at 2:46 AM, Sven Barth via fpc-devel wrote: I cannot speak for others, but I think 90% of potential use cases for ref counting would be covered like this in my code: objects that only live inside a procedure. I

Re: [fpc-devel] Defer keyword

2021-05-08 Thread Sven Barth via fpc-devel
Am 07.05.2021 um 17:40 schrieb Benito van der Zander via fpc-devel: The introduction of generics and their abundant use in Delphi has noticably slowed down the compiler and increased binary sizes. To my dismay, compile times of 20 seconds up to 2 minutes have become not uncommon in Delphi.

Re: [fpc-devel] Defer keyword

2021-05-08 Thread Jonas Maebe via fpc-devel
On 07/05/2021 07:26, Sven Barth via fpc-devel wrote: > Trunk also supports POSIX exceptions on selected *nix based systems, > though I haven't looked in depth yet in how far they incur a runtime > penalty (also they need to be enabled by enabling them in the compiler > and then recompiling

Re: [fpc-devel] Defer keyword

2021-05-08 Thread Jonas Maebe via fpc-devel
On 07/05/2021 18:41, Ryan Joseph via fpc-devel wrote: > Does that mean if you disable implicit exceptions then ALL ref counted types > leak memory? Only if an exception occurs. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 11:40 PM, Sven Barth 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

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Ryan Joseph via fpc-devel
> On May 7, 2021, at 9:40 AM, Benito van der Zander via fpc-devel > wrote: > > the classic Delphi way was to use an interface for freeing. It only requires > one type and nothing blows up. > That's clever but even try..finally is less overhead. Regards, Ryan Joseph

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Ryan Joseph via fpc-devel
> On May 7, 2021, at 2:46 AM, Sven Barth via fpc-devel > wrote: > > I cannot speak for others, but I think 90% of potential use cases for ref > counting > would be covered like this in my code: objects that only live inside a > procedure. > > I think the same. There's also a function

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Benito van der Zander via fpc-devel
Hi, Don't forget that the record/management operator approach will again blow up binary size; for every variable declared like this you risk creating a new type. the classic Delphi way was to use an interface for freeing. It only requires one type and nothing blows up. type   TDefer =

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Ryan Joseph via fpc-devel
> On May 7, 2021, at 3:08 AM, Michael Van Canneyt via fpc-devel > wrote: > > The introduction of generics and their abundant use in Delphi has noticably > slowed down the compiler and increased binary sizes. To my dismay, compile > times of 20 seconds up to 2 minutes have become not

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Michael Van Canneyt via fpc-devel
On Fri, 7 May 2021, Sven Barth via fpc-devel wrote: I thought it was agreed at the time that this was the most viable way forward ? As far as I remember there wasn't really any agreement. Can be, I was not sure... I remember this path was investigated. IIRC there was also the proposal

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Sven Barth via fpc-devel
Michael Van Canneyt via fpc-devel schrieb am Fr., 7. Mai 2021, 08:14: > > > On Fri, 7 May 2021, Sven Barth via fpc-devel wrote: > > > > > In my opinion the better solution is to continue the road that Maciej > > started and to implement that "default field" concept together with > > operator

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Michael Van Canneyt via fpc-devel
On Fri, 7 May 2021, Sven Barth via fpc-devel wrote: 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

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Sven Barth via fpc-devel
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 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

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Sven Barth via fpc-devel
Am 07.05.2021 um 00:17 schrieb Ryan Joseph via fpc-devel: On May 6, 2021, at 4:05 PM, Sven Barth via fpc-devel wrote: Other than that, you're right and what Ryan is trying to do is definitely the intended purpose of try ... finally. Is there any runtime code involved with try..finally or

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Nikolai Zhubr via fpc-devel
Hi, 07.05.2021 1:32, Ryan Joseph via fpc-devel: [...] it's kind of frustrating that we have ref counted types but that isn't extended to classes. Indeed. However, unfortunately classes are substantially different in that they can cause reference circles, which then cause damage to ref

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 4:26 PM, J. Gareth Moreton via fpc-devel > 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

Re: [fpc-devel] Defer keyword

2021-05-06 Thread J. Gareth Moreton via fpc-devel
There is some special handling involved in that the code inside the try part (I think) is effectively a nested procedure.  It's important in the context of stack unwinding when an exception occurs.  There is a performance penalty when using them, which one reason why the compiler sources don't

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 4:05 PM, Sven Barth via fpc-devel > wrote: > > Other than that, you're right and what Ryan is trying to do is definitely the > intended purpose of try ... finally. > Is there any runtime code involved with try..finally or does it just reorganize the code to run at the

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Sven Barth via fpc-devel
J. Gareth Moreton via fpc-devel schrieb am Do., 6. Mai 2021, 20:03: > The rule with try...finally is that, outside of something completely > catastrophic that destroys the program flow, is that once you enter the > try part, the finally part is guaranteed to be executed no matter how > you leave

Re: [fpc-devel] Defer keyword

2021-05-06 Thread J. Gareth Moreton via fpc-devel
The rule with try...finally is that, outside of something completely catastrophic that destroys the program flow, is that once you enter the try part, the finally part is guaranteed to be executed no matter how you leave it. Gareth aka. Kit On 06/05/2021 18:53, Ryan Joseph via fpc-devel

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 11:39 AM, J. Gareth Moreton via fpc-devel > wrote: > > In the example given: > > obj := TObject.Create; > defer objects.Free; > > What's wrong with Pascal's existing functionality? > > obj := TObject.Create; > try >... > finally >objects.Free; > end; > >

Re: [fpc-devel] Defer keyword

2021-05-06 Thread J. Gareth Moreton via fpc-devel
In the example given: obj := TObject.Create; defer objects.Free; What's wrong with Pascal's existing functionality? obj := TObject.Create; try ... finally  objects.Free; end; If there's a concern about performance penalty, maybe the compiler can work something out for

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 10:44 AM, Marco van de Voort via fpc-devel > wrote: > > But those types have refcounting built-in and always active. Things like > defer don't, which makes that all objects gets refcounting overhead in case > somebody needs it for "defer". > > Contrary to Pascal both

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Marco van de Voort via fpc-devel
Op 2021-05-06 om 17:38 schreef Ryan Joseph via fpc-devel: Something which annoys me about Pascal is cleanup in which a function exits in multiple places but there is no formal way to free memory which may be used in the current scope. I say ultimately Pascal needs some opt-in automatic