I have recently compiled projects which were converted from Delphi and it seems to me that the passing a function as a parameter does not require the '@' symbol. I suspect syntax errors came because I wasn't compiling from the command line.

e.g

function AFunction()
begin
end;

CallFunctionWithFunctionParameter (AFunction) instead of CallFunctionWithFunctionParameter (@AFunction)

Is passing a function as parameter without the '@' symbol accepted in Delphi?

If you use Delphi mode: yes.

Michael.

Yep.

And to me it looks "nicer than using "@", even though it is obviously sloppy syntax and introduces an ambiguity (what to to if a function has no parameter and returns a value that is a pointer to a function of exactly this type ?) ;-) .

-Michael

Michael Schnell wrote

what to to if a function has no parameter and returns a value that is a pointer to a function of exactly this type ?

​The logical thing for the compiler would be to assume that the programmer meant that a reference should be passed​. If the programmer wanted to invoke the function ans pass the result reference they should use empty parentheses aka "the invocation operator":

CallFunction(SomeFunction); // passes a reference to SomeFunction.
CallFunction(SomeFunction()); // passes the result of the invocation of
SomeFunction.

​So no ambiguity, albeit a very subtle semantic difference that can easily produce bugs.​ But IMHO the "@" notation isn't much better either.

PS: I tend to always use the "()" notation when invoking functions with no arguments so it will be clear to a future reader that I'm invoking a function and not assigning some variable. Makes a difference with poorly named functions (not starting with a verb):

ADate := Date;
ADate := Date();

Constantine Yannakopoulos wrote

PS: I tend to always use the "()" notation when invoking functions with no arguments so it will be clear to a future reader that I'm invoking a function and not assigning some variable.

This should be the job of the langugage definition, not of the programmer: Avoid ambiguity, do not base anything on assumptions. That avoids bugs by making it very clear to the programmer what realy happens.

Saving one or 2 key keystrokes is of no use.
A clear language definition is what makes the essence of a programming language.

Compilers should not assume. Programmers should be explicit about what they want.
Assumptions based on ambiguous semantics are an unending source of problems.

Constantine Yannakopoulos wrote

So no ambiguity,

As - other than in C - calling a function without empty parentheses is allowed (and rather common, FWIW), this _is_ an ambiguity.

-Michael

More questions on Mode Delphi.

1. Does Mode Delphi simply allow Delphi syntax to be compiled, or does it also affect the code generation, like data structures, pointer handling, parameter handling / calling conventions, stack frames etc?

2. When Mode Delphi is applied to a project, ie the .dpr, does it affect the whole project, or does each project require its own mode delphi statement?

3. Can it be switched on and off within the same unit, ie some procedures and data structures use it, some don't?

Compared to mode objfpc: no.
Other modes might have other aligns and calling conventions. But you can change that with compiler directives, so basically a mode is just a nice set of start switches.

2. When Mode Delphi is applied to a project, ie the .dpr, does it affect the whole project, or does each project require its own mode delphi statement?

The command line parameters are applied to the whole project, the compiler directives only to the unit.

3. Can it be switched on and off within the same unit, ie some procedures and data structures use it, some don't?

See compiler directives.

Mattias