Am 28.11.2021 um 14:21 schrieb Ryan Joseph via fpc-pascal:
On Nov 28, 2021, at 7:01 PM, Sven Barth <pascaldra...@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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
