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