Manual resource management is not a “broken” system. It’s just a different one. One that can be more efficient than automatic garbage collection.

But I don’t see how it would make any transition to a fully auto GC’d Delphi more difficult. Far from it.

With the “automated” keyword, an auto-GC’d Delphi compiler would simply ignore the keyword.

WITHOUT the “automated” keyword the compiler would still be required to compile the explicit manual resource management code (indistinguishable to the compiler from any other compilable code), so the RTL would need to create facade support for certain operations that would be NO-OPs at runtime.

This was one of the *mistakes* (imho) that was made with Delphi.NET.

So if anything, an “automated” keyword would be a useful step toward GC.

Not-with-standing the fact that I believe that a GC in (native code) Delphi would be a mistake.

If you want to write with a GC, just use .NET.

procedure foo;
var
list : TList.Create & finally free;
begin
[...]
end;

procedure foo;
var
list : TList := TList.Create & finally free;
begin
[...]
end;

procedure foo;
var
list : TList := nil
begin
[...]
finally
list.free;
end;

or even better:

procedure foo;
var
list : TList := TList.Create;
begin
[...]
finally
list.free
end;

But if you don’t like it you don’t have to vote for it, and even if it’s implemented, you wouldn’t have to use it.

http://www.deltics.co.nz/blog/?p=391

In the meantime i’d be happy enough for some common objects that automatically clean up after themselves, e.g. TSafeStringList, TSafeList, TSafeBitmap, etc.

TSafeStringList alone would save me about 5000 lines of code each day

As regards your other point, there is no guess work. The “automated” keyword is as explicit about the behaviour of that variable as “absolute” is, or “abstract” is for method declarations (or “empty” in Oxygene, for example).

You could achieve the same things by being more explicit (*) and then seeing the behaviour expressed in the code (or by seeing it NOT expressed, in the case of an empty/abstract method – ), but the declaration encapsulates it for you, allowing the code to be free of mundane housekeeping jobs.

(*) e.g. in the case of “absolute”:

procedure TSomeForm.OnControlEnter(Sender: TObject);
var
listbox: TListbox absolute Sender;
edit: TEdit absolute Sender;
…
begin
if Sender is TListbox then
listbox.Color := …
else if Sender is TEdit then
edit.Color := …
…
end;

vs

procedure TSomeForm.OnControlEnter(Sender: TObject);
var
listbox: TListbox;
edit: TEdit;
…
begin
if Sender is TListbox then
begin
listbox := TListbox(Sender);
listbox.Color := …
end
else if Sender is TEdit then
begin
edit := TEdit(Sender);
edit.Color := …
end
…
end;

i.e. with “absolute” you still have to exercise exactly the same cautions that you have to exercise when achieving the same thing “the long way around” – type checking etc – but as long as you are doing that, the actual implementation details you are protecting by exercising that caution are taken care of for you.

This isn’t quite the same, as this “long hand” way is not directly comparable to, and is slightly less efficient than, the language supported capability. The directly comparable “long hand” implementation would be even more error prone as it would involve using pointers which can easily trip up even the most cautious developer.

“automated” on the other hand is directly comparable to existing “long hand” techniques but it also protects the developer from incorrect use of those techniques.

e.g. I still quite often see try..finally being incorrectly used:

try
list := TList.Create;
// …
finally
list.Free;
end;

The developer has understood what they need to do, but hasn’t grasped the finer points of the runtime behaviour of exceptions and constructors and learned to apply that (or perhaps carelessly forgot in this one instance, which perhaps involve multipled temp objects, where the try..finally’s can get messy).

Had they applied the same intention by marking “list” as automated, those details would have been take care of.

And all those 2 cents add up to a useful contribution in the end.