[fpc-pascal] Named optional arguments

[Sven Barth]

Am 26.11.2021 um 05:10 schrieb Ryan Joseph via fpc-pascal:
> This was discussed before some years ago with no conclusion (https://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg46280.html) but I'd like to bring it up again. Can we consider extending the variant dispatch call named parameters to normal functions? The majority of the infrastructure is already there so it needs to merely be extended.
>
> This is what the syntax would look like:
>
>    SetupCanvas(width := 500,
>                           height := 500,
>                           eventCallback := @HandleCanvasEvents,
>                           options := [TCanvasOption.VSync]);
>
> The reason for this is of course to handle functions with many parameters so we don't need to look at the function definition to know which params mean what thing.
>
> C# has effectively added optional named parameters along with other languages I use and I consider this a solid development at this point. My complaints come with languages like Swift where the parameter names are meant to be part of the function signature and really clutter up the language in my opinion so I'd like to avoid that by making it opt-in, like C#.
>
> The basic idea:
>
> - Opt-in design so if you name the first parameter in a function all following parameters must be named, and the inverse, if the first parameter is not named the following parameters can not be named either.
> - Consider the parameter name during overloading resolution so that even if the values are correct the names must match also.
> - Enabled with a mode switch?
> - Parameters can be specified in any order?

I'm against it for multiple reasons:

The compiler does not know which routine is called upon parsing the 
parameter declarations (which would mean that error reports would need 
to be deferred until the lookup of the routine failed).

What would be called in this situation:

// unit A
procedure Foo(aArgStr: String = ''); overload;
// unit B
procedure Foo(aArgInt: LongInt = 0; aArgStr: String = ''); overload;

// unit C
Foo(aArgStr = 'Foo');

(Side note: yes, if no parameter would be given, the compiler would 
already complain about an ambigous call)

This would also introduce a possibility of subtle bugs, in addition to 
those that already exist for overloading. Take the example above, but 
without the "overload" directive: If the uses-clause in unit C would be 
"UnitA, UnitB" then the "Foo" from unit B would be called and if it 
would be "UnitB, UnitA" then the one from unit A would be called. 
Without named arguments there would be a compile error due to a 
mismatched argument.

Also this complicates overload selection (especially with an out of 
order use of the parameters) and overload selection is already 
complicated enough.

Regards,
Sven