[fpc-pascal] Named optional arguments

[Sven Barth]

Am 28.11.2021 um 14:21 schrieb Ryan Joseph via fpc-pascal:
>
>> On Nov 28, 2021, at 7:01 PM, Sven Barth <pascaldragon at googlemail.com> wrote:
>>
>> Anything that relates to picking functions *must* be part of the overload handling. You can easily see this with your named argument proposal when not all arguments are named (and then the compiler also needs to check that unnamed parameters aren't used for named ones as well, this gets more complicated if the overloads have different argument names).
>>
>> You should have already learned this lesson when I pointed you in the right direction for the implicit function specializations.
>>
> I'm not proposing we necessarily allow the reordering of arguments or allow omitting of values. In the simplest scenario they're just optional names but the parameters still need to be provided in the correct order. Very simply to make reading long functions easier at the call site.

If you don't allow to skip parameters then this feature can be 
considered absolutely useless. Who would voluntarily write more when 
many users already cry about Pascal being so verbose?

> Yes I understand that the overloading happens after parsing. In your first example if arbitrary order was allowed new overloading rules would need to be applied so that you got an ambiguous function error. Not a big deal to resolve that I would think but it doesn't have to go in that direction either.
>
> Personally I'm not in favor or changing the overloading rules, just that some calls were easier to read by glancing over them. In fact I have seen IDEs which have a feature which inserts the param name into the editor for this very reason.

You still don't get it. This is not about "changing the overloading 
rules" but about this feature fitting into the existing overload 
selection functionality.

Take the following example:

=== code begin ===

procedure Test(aArg1: String; aArg2: LongInt = 42; aArg3: String = '');
procedure Test(aArg1: LongInt; aArg2: String = '');

// somewhere else
Test('Foobar', aArg3 := 'Hello World');

=== code end ===

Now when the compiler encounters the symbol "Test" it roughly plays out 
like this:

1. Detect that "Test" is a procsym
2. Collect all suitable overloads
3. for each overload iterate all provided parameters
   1. is it a named parameter?
     1. does the name match a named parameter after the last unnamed or 
named one?
       1. no -> not a suitable overload
       2. yes -> retrieve default value of parameters between last one 
and this one and use this parameter value (and make sure that the value 
is suitable for the parameter type)
     2. name matches an existing previous parameter? -> not a suitable 
overload
     3. duplicate name? -> report error about duplicate parameter use 
(could maybe be done while parsing already)
     4. name does not match any parameter? -> not a suitable overload
   2. parameter value suitable for the parameter? (essentially existing 
overload checks)
4. if no suitable overload was found then report found overloads and 
error out
5. if multiple suitable overloads were found then reprot found suitable 
overloads and error out

This is of course a simplification, but you can easily see that it needs 
to fit snuggly into the overload selection code provided by 
tcallcandidates, because it needs to handle cases with mixed named and 
unnamed parameters.

> As an aside, is it even useful to allow arbitrary parameter order? I don't recall ever wanting this and would open the door to some functions being called in different order across a codebase, which sounds like a big problem unto itself (C# allows this btw).

You provided that as a possible suggestion, so I went with it to humor you.

Additional drawback of named arguments: refactoring a routine's 
parameter names would also mean that ore can have problems with 
backwards compatibility if one decides to rename a parameter (because it 
turned out to be badly named), cause this would lead to compile time 
errors once the parameter name of the declaration is changed, but not at 
the call sites (and now imagine one of us changing a parameter name in 
some important RTL function and users using that in their code).

I don't care that other programming languages think of this as a nice 
feature, *I* don't.

Regards,
Sven