Why compiler allows this difference in declaration?

[Mike Torrettinni 198]

Is this a compiler flaw in Delphi 10.2.3:

 

it allows this:

procedure Run(const aText: string = '');

implementation
  
procedure Run(const aText: string);
begin
end;

but not this (error E2037):

procedure Run(const aText: string);

implementation
  
procedure Run(const aText: string = '');
begin
end;

 

Shouldn't it complain the same in both cases?:

E2037 Declaration of 'Run' differs from previous declaration

 

[Remy Lebeau 1255]

No, it is not a flaw.  This is how Delphi (probably even Pascal in general) has always worked.

 

A parameter's default value is required only in the function's declaration.  At any site where the function is called, the compiler needs to know what the default value is, if the calling code decides to omit the parameter.

 

Duplicating the default value in the function's implementation is optional.  The implementation doesn't care whether the caller omitted parameters or not, because the compiler will have filled in any missing values on the call stack before the implementation is entered.

Edited August 17, 2021 by Remy Lebeau

[Mike Torrettinni 198]

12 minutes ago, Remy Lebeau said:

A parameter's default value is required only in the function's declaration.  At any site where the function is called, the compiler needs to know what the default value is, if the calling code decides to omit the parameter.

Make sense. I didn't see it that way, I just thought it simply compares declarations.

 

But it make sense now why also overload override forward inline keywords behave the same. Thanks!

[Guest]

In Pascal the following is also OK

procedure Run(const aText:string = '');
procedure Run2(const aText:string);

implementation

procedure Run;
begin
end;

procedure Run2;
begin
end;

While this

procedure Run3;

implementation

procedure Run3(const aText:string);
begin
end;

Will fail with two different compiling errors (notice the line numbers)

Quote

[DCC Error] uMain.pas(44): E2267 Previous declaration of 'Run3' was not marked with the 'overload' directive

[DCC Error] uMain.pas(25): E2065 Unsatisfied forward or external declaration: 'Run3'

 

[Mike Torrettinni 198]

6 hours ago, Kas Ob. said:

in Pascal the following is also OK 

procedure Run(const aText:string = '');
implementation

procedure Run;

 

 

This is interesting, it seems to allow even more than 1 parameter:

procedure Run(const aText:string = ''; const aText2: string = ''; const aText3: string = '');

And code completion recognizes parameters:

 

 

[Lars Fosdal 1730]

I sometimes wish I could call Delphi code in SQL style.

Run(aText2='my text'); 

i.e. specify individual parameter(s) and leave the rest as their default.

 

 

[Pat Foley 50]

8 minutes ago, Lars Fosdal said:

I sometimes wish I could call Delphi code in SQL style.

Run(aText2='my text'); 

i.e. specify individual parameter(s) and leave the rest as their default.

 

 

Quote

//Running Delphi Applications With Parameters
By Zarko Gajic
Updated February 02, 2019
Though it was much more common in the days of DOS, modern operating systems also let you run command line parameters against an application so that you can specify what the application should do.

The same is true for your Delphi application, whether it be for a console application or one with a GUI. You can pass a parameter from Command Prompt in Windows or from the development environment in Delphi, under the Run > Parameters menu option.
//

  

[Lars Fosdal 1730]

@Pat Foley - That is something entirely different. I was talking about naming parameters to a method.

[Pat Foley 50]

27 minutes ago, Lars Fosdal said:

@Pat Foley - That is something entirely different. I was talking about naming parameters to a method.

Oops. sidetracked into Application.Run 

[Alexander Elagin 143]

2 hours ago, Lars Fosdal said:

I sometimes wish I could call Delphi code in SQL style.

Run(aText2='my text'); 

i.e. specify individual parameter(s) and leave the rest as their default.

 

 

In fact, Delphi supports named parameters, but only for automation (OLE/COM) objects. Like this (from http://www.blong.com/articles/automation in delphi/automation.htm):

  //An Automation method call, using two named parameters
  MSWord.Selection.InsertDateTime(
    DateTimeFormat := 'dddd, dd MMMM yyyy',
    InsertAsField := False);
  MSWord.Selection.TypeParagraph;

 

[Lars Fosdal 1730]

Interesting.  I wonder why it was limited to the OLE/COM scope?

[Arnaud Bouchez 380]

IIRC it was almost mandatory to work with Ole Automation and Word/Excel.

Named parameters are the usual way of calling Word/Excel Ole API, from Office macros or Visual Basic. So Delphi did have to support this too.

 

And it is easy to implement named parameters with OLE. Because in its ABI, parameters are... indeed named.

Whereas for regular native code function ABI, parameters are not named, but passed in order on registers or the stack.

So implementing named parameters in Delphi would have been feasible, but would require more magic, especially for the "unnamed" parameter.

 

It was requested several times in the past, especially from people coming from Python background.
Named parameters can make calls more explicit.
So the question is more for Embarcadero people. 😉

 

You can emulate this using a record or a class to pass the values, but it is not as elegant.

[Fr0sT.Brutal 897]

4 hours ago, Arnaud Bouchez said:

IIRC it was almost mandatory to work with Ole Automation and Word/Excel.

Named parameters are the usual way of calling Word/Excel Ole API, from Office macros or Visual Basic. So Delphi did have to support this too.

I never saw naming the parameters but saw all these tremenous lists of overloads: one param, two param. three param, ... scary

[Mike Torrettinni 198]

On 8/17/2021 at 10:32 AM, Alexander Elagin said:

In fact, Delphi supports named parameters, but only for automation (OLE/COM) objects. Like this (from http://www.blong.com/articles/automation in delphi/automation.htm):

  //An Automation method call, using two named parameters
  MSWord.Selection.InsertDateTime(
    DateTimeFormat := 'dddd, dd MMMM yyyy',
    InsertAsField := False);
  MSWord.Selection.TypeParagraph;

  

 

Shame they didn't adopt this and implement everywhere.

 

12 hours ago, Arnaud Bouchez said:

IIRC it was almost mandatory to work with Ole Automation and Word/Excel.

Perhaps we should request they add 'mandatory' flag to feature requests 🙂