This was discussed before some years ago with no conclusion () 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?

Regards,
Ryan Joseph

That seems like a fake argument: Of course you need to look, because you need the names ? Secondly, the IDE will simply tell you what the names are when the cursor is on them.

Michael.

It's mainly useful when reading code so you don't need to review the function definition, using code tools or any other method. I've been enjoying it in other languages when it's not compulsory and FPC already supports the syntax so I thought it would be low hanging fruit.

Regards,
Ryan Joseph

On Nov 26, 2021, at 4:20 PM, Ryan Joseph wrote: It's mainly useful when reading code so you don't need to review the function definition, using code tools or any other method. I've been enjoying it in other languages when it's not compulsory and FPC already supports the syntax so I thought it would be low hanging fruit.

I wanted to add a little case study from the compiler itself to see how to make some really long function more readable.

1) Original form (the compiler doesn't use spaces between punctuation). Very difficult to read if nothing else because the lack of spaces but it's also not clear at all which params are which. Even code tools are going to not help very much unless they can hilight the parameters in the editor. Either way you're going to be spending time try to figure this one out.

candidates:=tcallcandidates.create(symtableprocentry,symtableproc,left,ignorevisibility,
  not(nf_isproperty in flags),cnf_objc_id_call in callnodeflags,cnf_unit_specified in callnodeflags,
  callnodeflags*[cnf_anon_inherited,cnf_inherited]=[],cnf_anon_inherited in callnodeflags,spezcontext);

2) Adding some line breaks helps a lot but it's still not clear what some of the params are unless you jump to the function definition or get a tool tip on the constructor and then even so you need to count the params to see which is which, and this takes time and effort.

candidates:=tcallcandidates.create(symtableprocentry, symtableproc,
left,
ignorevisibility,
not(nf_isproperty in flags),
cnf_objc_id_call in callnodeflags,
cnf_unit_specified in callnodeflags,
callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], cnf_anon_inherited in callnodeflags,

                                                            spezcontext);

3) Clearly defined names each on their own line is obviously the easiest to read at a glance. Even if no line breaks were present the editor could style the param names a different color and they would be easy to read.

candidates:=tcallcandidates.create(sym:=symtableprocentry,
                                                            st:=symtableproc,
                                                            ppn:=left,
                                                            ignorevisibility:=ignorevisibility,
                                                            allowdefaultparas:=not(nf_isproperty in flags),
                                                            objcidcall:=cnf_objc_id_call in callnodeflags,
                                                            explicitunit:=cnf_unit_specified in callnodeflags,
                                                            searchhelpers:=callnodeflags*[cnf_anon_inherited,cnf_inherited]=[],
                                                            anoninherited:=cnf_anon_inherited in callnodeflags,
                                                            spezcontext:=spezcontext);

4) For contrast here's a bad example of named params which we want to avoid. Languages like Swift encourage this kind of thing and I think it's less readable and adds clutter.

pt := MakePoint(x:= 1, y := 2);   // cluttered and doesn't add any useful information
pt := MakePoint(1, 2);                // normal calling syntax, easy to read and clean

Regards,
Ryan Joseph

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

The use case is irrelevant, because

a) if named arguments would be used in the compiler it would be used as

candidates:=tcallcandidates.create(sym:=symtableprocentry,
st:=symtableproc,ppn:=left,
ignorevisibility:=ignorevisibility,allowdefaultparas:=not(nf_isproperty
in flags),objcidcall:=cnf_objc_id_call in
callnodeflags,explicitunit:=cnf_unit_specified in
callnodeflags,searchhelpers:=callnodeflags*[cnf_anon_inherited,cnf_inherited]=[],
anoninherited:=cnf_anon_inherited in
callnodeflags,spezcontext:=spezcontext);

So you've gained *nothing*.

b) more often then not you need to look at the declaration or even the implementation anyway to know what the function is doing or expecting due the lack of up-to-date and complete documentation

Regards,
Sven

Ryan Joseph wrote

1) Original form (the compiler doesn't use spaces between punctuation). Very difficult to read if nothing else because the lack of spaces but it's also not clear at all which params are which. Even code tools are going to not help very much unless they can hilight the parameters in the editor.

That's exactly what Lazarus does: place your cursor on any of the parameters and press ctrl-shift-space. It will show you the declaration with the current parameter in bold.

Jonas

On Nov 27, 2021, at 5:00 PM, Sven Barth wrote: 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).

My idea was to not actually have it affect overloading except in the case where the param names don't match which would ignore the call (so in your example below nothing changes).

Otherwise if the name was actually part of the overloading we would have to allow functions with the same parameter type but different names, i.e.:

procedure Foo(Arg1: String = '');
procedure Foo(Arg2: String = '');

and that would be a big change to the language and have all sorts of implications.

So it's really just a minor hint to make the call more readable in the case of long function names.

Regards,
Ryan Joseph

I wouldn't say nothing but it's still really hard to read. My only thought there was that it would open the door for some syntax coloring on the parameter name so you can scan them easier.

Regards,
Ryan Joseph

Ryan Joseph wrote

[...]The majority of the infrastructure is already there so it needs to merely be extended.

What do you mean? Is there already some call by arg names in some mode(switch)?

Mattias

No, it's only there for IDispatch support:
https://stackoverflow.com/questions/885942/named-optional-parameters-in-delphi

Jonas

On Nov 28, 2021, at 4:18 PM, Mattias Gaertner via fpc-pascal wrote: What do you mean? Is there already some call by arg names in some mode(switch)?

I mean all the plumbing is there so the feature could easily be extended from IDispatch to work with normal function calls.

Regards,
Ryan Joseph

Ryan Joseph via fpc-pascal schrieb am
So., 28. Nov. 2021, 05:32:

Lazarus already highlights commas differently, so one can easily differentiate the parameters.

Regards,
Sven

Ryan Joseph via fpc-pascal schrieb am
So., 28. Nov. 2021, 03:12:

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.

Regards,
Sven

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.

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.

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).

Regards,
Ryan Joseph

The only thing that is there is the parsing and that is the smallest part of implementing this functionality. You absolutely underestimate what is involved with this.

Regards,
Sven

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

On Dec 1, 2021, at 4:56 AM, Sven Barth wrote: 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?

I thought the option of improved readability made sense for a language like Pascal.

No I really do understand what the situation is if you can believe me. I don't see this is a big problem or too complicated to tackle but if you really dislike the idea so much then we'll leave 's more important potential features to work on anyways.

btw kind of off topic did you like my idea of default properties for records so we can implement smart pointers? I got a good chunk of that done months ago but never heard anything about it...

Regards,
Ryan Joseph