> 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.
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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
