Incorrect, inline variables are about lifecycle too, not only for the HL visibility rules. They must be created/destroyed immediately after entering/leaving their scope/compound, otherwise they will be equally useless, imagine auto_ptr<> equivalent.
I mean... it would make sense to build it like that, but thats not necessarily the case. Currently FPC has no concept of scope related lifetime. Example:
type
generic TAutoFree<T: TObject> = record
ptr: T;
class operator Finalize(var rec: specialize TAutoFree<T>);
end;
class operator TAutoFree.Finalize(var rec: specialize TAutoFree<T>);
begin
rec.ptr.Free;
end;
generic function AutoFree<T: TObject>(AObject: T): specialize TAutoFree<T>;
begin
Result.ptr := AObject;
end;
// Usage
procedure Foo;
begin
// ...
With specialize AutoFree<TStringList>(TStringList.Create) do
begin
ptr.Add('Hello');
ptr.Add('World');
ptr.SaveToFile('test.txt');
end;
// ...
end;
Here a new scope is introduced where the temporary object of the AutoFree call lives, and access to ptr is granted. But even though the scope is limited, the actual lifetime will still be that of the function (well its undefined, but in experiments the FPC does it this way).
So just adding scoping is easy, as I showed some time ago, a rough implementation of inline variables can be done in a few hours. But this does not mean we get also scoped lifetimes and stuff like that.
Scoped lifetimes need a much more thorough change to the FPC than "simple" inline variables do.
Hello,
@Ryan J if you want inline variables there is a solution with anonymous procedure:
And if you're very lazy you can even write a macro:
{$Macros On}
{$Macro inlinevar:=TProcedure(procedure var}
{$Macro vend:=end)()}
// Usage
inlinevar i, j: Integer;
begin
// use inline vars here
vend;
And I think in mode MacPas you can even export macros, making it includable.