Feature Request: Relaxing the constraints on default values in formal paramters

[EganSolo]

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][+][-]

1. Type
2.   TBook = class end;
3.   TBookType = class of TBook;
4. const
5.    aBookType : TBookType = TBook;
6.  
7. //The compiler throws "Illegal  expression at TBook below
8. Procedure FooBar(const aBookType: TbookType = TBook);
9.  

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]

Aside 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]

Thanks, Serge,

As the docs state:

For 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]

I'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]

ASerge, please consider this fully functional program:

Code: Pascal  [Select][+][-]

1. program Project1;
2.  
3. Type
4.   FuncType = function: Boolean;
5.  
6.   Function A : Boolean;
7.   begin
8.     Result := true;
9.   end;
10.  
11. const
12.   ft : FuncType = @A;
13. begin
14.   Writeln('ft = ', ft);
15.   Readln;
16. end.
17.  

You stated:

If 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]

ASerge, 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.

In that case, its address could be relocated in memory during loading.

Function address - yes, but not some parameters in call stack

[EganSolo]

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?