Feature Request: Relaxing the constraints on default values in formal
paramters
lazarus / 64-FPC development

----------------------------------------------------------------------
EganSolo · 2025-08-07 20:03

This is an offshoot from this thread:
https://forum.lazarus.freepascal.org/index.php/topic,71955.0.html

To summarize, consider this bit of code:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i Type  TBook
= class end;  TBookType = class of TBook;const   aBookType : TBookType
= TBook; //The compiler throws "Illegal  expression at TBook
belowProcedure FooBar(const aBookType: TbookType = TBook); 
Request: Is it possible to relax the restrictions governing default
values for formal parameters to match those of typed constants? Aside
from Delphi compatibility, is there a technical reason why that won't
work?

Thanks.

----------------------------------------------------------------------
ASerge · 2025-08-07 20:35

Quote from: EganSolo on August 07, 2025, 10:03:38 pmAside from Delphi
compatibility, is there a technical reason why that won't work?
This is documented in Value parameters: For dynamic arrays or other
types that can be considered as equivalent to a pointer, the only
possible default value is Nil.

----------------------------------------------------------------------
EganSolo · 2025-08-07 22:02

Thanks, Serge,

As the docs state:

QuoteFor a parameter of a simple type (i. e. not a structured type), a
default value can be specified. This can be an untyped constant.
I'm asking if it's possible to relax that restriction to allow more
flexible constants to be passed as default parameters.

----------------------------------------------------------------------
ASerge · 2025-08-07 22:19

Quote from: EganSolo on August 08, 2025, 12:02:07 amI'm asking if it's
possible to relax that restriction to allow more flexible constants to
be passed as default parameters.
Unlike declaring a constant, when calling a function with a default
parameter, will have to substitute this "constant" every call. If we
allow pointer types, then pointers to functions will also get there,
and the latter can be relocated in memory during loading.

----------------------------------------------------------------------
EganSolo · 2025-08-07 23:40

ASerge, please consider this fully functional program:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i program
Project1; Type  FuncType = function: Boolean;   Function A : Boolean; 
begin    Result := true;  end; const  ft : FuncType = @A;begin 
Writeln('ft = ', ft);  Readln;end. 
You stated:
QuoteIf we allow pointer types, then pointers to functions will also
get there, and the latter can be relocated in memory during loading.
What's different with ft? Admittedly, my example is simplistic, but
you could imagine Function A located inside a dll, no? In that case,
its address could be relocated in memory during loading.

In the case of a function call, the compiler would set up a symbolic
address during compilation and resolve it during linking. Effectively,
isn't that similar to dynamic binding?

----------------------------------------------------------------------
ASerge · 2025-08-08 14:32

Quote from: EganSolo on August 08, 2025, 01:40:14 amASerge, please
consider this fully functional program:
What's different with ft?
ft is assigned only once. When you use a function, need to substitute
it every time you call it.

QuoteIn that case, its address could be relocated in memory during
loading.
Function address - yes, but not some parameters in call stack

----------------------------------------------------------------------
EganSolo · 2025-08-09 01:29

But isn't the substitution taking place during linking? What's the
harm if we extend that ability to cover typed functional parameters?
Why can't we extend the compiler to do this:

1. During the compile phase, replace a typed constant assigned to a
formal parameter with a symbolic address.
2. During the linking phase, replace the symbolic address with a
physical one.

There must be some complication level I'm missing ...

Additionally, we could extend default values to classes, as seen in my
first example, and include other values that do not suffer from memory
relocation, while also forbidding functional values. I mean, there are
options here, no?