It's not about your personal preferences or technical needs. It's all about marketing (minimum standards to use "modern language" brand in advertising
).
New developers will come (with experience of languages with closures) and they'll use it with Delphi/FPC. Eventually forcing everyone else (good-
old-experienced developers) to use it (just because you might have to debug the code or work with component that's using it).
Sad, but true.
Using closures in "threads" is questionable.
This is how I'd do it today:
type
TDataForThread = class(TObject)
// put some data here
end;
procedure InitThread;
var
d : TDataForThread;
begin
d:=TDataForThread.Create;
d.Gathet();
StartThread( @ProcThread, d);
end;
procedure ProcThread(data: Pointer);
var
d : TDataForThread;
begin
d:=TDataForThread(data);
// do the work
d.Free; // or not d.Free, depending on how you use it.
end;
Benefit - I've full control on how and when the memory is allocated / copied and released.
If I'd do it using closures (anonymous functions), it might look like this: (which is less typing, but looks ugly):
..
StartThread( procedure
begin
// do the work
end)
..
I'm loosing control over how/when and what is being released / allocated. Which makes me think about unnecessary growing memory consumption and possible AVs (as mentioned earlier in this thread).
Recent
