[fpc-pascal] Auto vars (again)

[Ryan Joseph]

> On Aug 17, 2018, at 7:50 PM, Maciej Izak <hnb.code at gmail.com> wrote:
> 
> 2018-08-18 1:24 GMT+02:00 Ryan Joseph <ryan at thealchemistguild.com>:
> but is there any merit to this idea if it was cleaned up and made safe? I did some tests to see if you could prevent passing auto vars out of scope and it’s possible to prevent most ways but not 100%.
> 
> You are trying to achieve something what is almost possible with current FPC trunk version (which is also safe in the case of exception):
> 
> var
>   o: TAutoCreate<TObject>;
> begin // auto Create
>   Writeln(o._.ToString); 
> end. // auto Free;
> === code end ===
> 
> the code above was not tested (written now) but should work. The only disadvantage of above solution is lack of the way to omit "_”. 

I think you may be right about this. Having “auto” leverage the existing management operators makes sense. It’s more overhead to wrap everything in records though and the larger problem is the so-called syntactic sugar missing.

> 
> The solution which probably should be accepted by fpc team is default property without indexer:
> 
> === code begin ===
> property obj: T read fobj; default;
> === code end ===
> 
> with this property should be possible:
> 
> === code begin ===
> Writeln(o.ToString); 
> === code end ===

How does that property work exactly? Making this work properly is the most important part but I never considered it. It sounds like “with” statements kind of.

> 
> next you can try to provide compiler magic:
> 
> === code begin ===
> var o: TObject auto; // equivalent of var o: TAutoCreate<TObject>;
> // please note that syntax with semicolon is improper: 
> //var o: TObject; auto; 
> === code end ===

I wasn’t sure what’s proper. Function modifiers look like that but there are no var modifiers in Pascal as of now. The absolute keyword is kind of similar. We have “threadvar” also which sets a precedence and starts a new section which is nice. Either way I really like the idea of introducing a keyword instead of using the generic <> syntax.

> 
> anyway I am not big fan of "auto" because it means many troubles, what if:
> 
> * there is no parameter less constructor

That’s the biggest problem IMO. Calling NewInstance is correct, you’re right, but if the class needs parameters you need to call the constructor again anyways so it kind of defeats the purpose. When the class has only a parameterless constructor it works beautifully though so the feature is limited to those cases.

> * why to call constructor when there is NewInstance (this seems more proper for this case but...)
> 
> after NewInstance you can (and rather this will be necessary) call selected constructor from instance which will be executed like regular method, but what is the sense of "auto" calling NewInstance when you still need to execute Constructor? :D

Agreed, that limits the usefulness of the feature. When it works well it’s a real win though.

> 
> I see rather no reason for this feature in compiler (but nice try :) ). There are many other directions to solve "auto free" problems without compiler modifications - maybe not all can be solved but many problems for sure - for example you have ready to use TAutoFree from mORMot or initial experiments with ARC objects for NewPascal (still worth to mention ;P).

How does TAutoFree in mORMot work? Never heard of this.

Full blown ARC is probably the best option but I was thinking of intermediate steps that are easy to implement and solve a a portion of the common use cases. It’s a poor mans ARC at best. ;)

Regards,
	Ryan Joseph