[CLOSED (almost)] Mixed "procedure" and "procedure of object" callback

[PascalDragon]

Not to say that currently procedure/function are the keywords starting the inlined subroutine.
Why adding "with" to that list?

Indeed. If the parser encounters a procedure or function inside a routine it immediately knows: oh, an anonymous function! However if the parser sees a with it needs to parse quite a lot more before it can decide whether it's dealing with a with-clause or an anonymous function. Pascal is not only about readability, but also about ease of parsing.

[Otto]

I fully understand your point of view and the need to introduce a different behavior in the FPC compiler than Delphi.
However, I imagine that for a time there will have to be comparative tests and validations between codes written in FPC and other programming languages (particularly Delphi). My proposal, in my opinion, would facilitate this phase; {further, in a broader perspective, it could be used to simplify the introduction of new programming paradigms in FPC}.
I had already considered the right objection put by Martin_fr, proposing an alternative reserved word.
The hypothetical code could be e.g.:

Code: Text  [Select][+][-]

1. Capture (a, var b, const c) begin // facoltativo [Optional]
2.  procedure Foo begin ... end
3. end; // facoltativo [Optional]

During the validation phase it would be enough to put "FPC mode" only in the row containing Capture (and the possible end if you wanted to implement it); in particular, this would simplify the readability of the code in Delphi.
From the information provided to me in other posts, I have inferred that technically my proposal would not be impossible. The compiler encountering the reserved word "Capture" would be notified of a subsequent presence of an anonymous function.
Of course I understood that if you applied this idea, you would get some further complication to the compiler; However, in my opinion, any future benefits should be assessed.

Thank you for the time spent reading my post.

[PascalDragon]

I fully understand your point of view and the need to introduce a different behavior in the FPC compiler than Delphi.
However, I imagine that for a time there will have to be comparative tests and validations between codes written in FPC and other programming languages (particularly Delphi). My proposal, in my opinion, would facilitate this phase; {further, in a broader perspective, it could be used to simplify the introduction of new programming paradigms in FPC}.
I had already considered the right objection put by Martin_fr, proposing an alternative reserved word.
The hypothetical code could be e.g.:

Code: Text  [Select][+][-]

1. Capture (a, var b, const c) begin // facoltativo [Optional]
2.  procedure Foo begin ... end
3. end; // facoltativo [Optional]

During the validation phase it would be enough to put "FPC mode" only in the row containing Capture (and the possible end if you wanted to implement it); in particular, this would simplify the readability of the code in Delphi.
From the information provided to me in other posts, I have inferred that technically my proposal would not be impossible. The compiler encountering the reserved word "Capture" would be notified of a subsequent presence of an anonymous function.
Of course I understood that if you applied this idea, you would get some further complication to the compiler; However, in my opinion, any future benefits should be assessed.

Thank you for the time spent reading my post.

No. Why should there be another clause added? Especially one that is useless if it isn't followed by an anonymous function? Not to mention that I want to use this also for nested functions and for that a clause around them makes no sense. No, making it part of the function header is the sensible approach.
Also with a new keyword there is the problem of backwards compatibility: there might be code out there that uses capture as a variable or type name. There is however no code out there that uses procedure or function, because already today that would need to be escaped using &.

[Otto]

Surely you have all the elements to implement all the features consistently with each other.  It is also possible that, in the future, Delphi may adopt the same standards as you.