Named arguments

[Jonathan M Davis]

On Wednesday, October 25, 2017 06:23:52 bauss via Digitalmars-d wrote:
> On Tuesday, 24 October 2017 at 22:08:57 UTC, Jonathan M Davis
>
> wrote:
> > On Tuesday, October 24, 2017 13:36:00 H. S. Teoh via
> >
> > Digitalmars-d wrote:
> >> On Tue, Oct 24, 2017 at 01:22:41PM -0600, Jonathan M Davis via
> >>
> >> > It also wouldn't play well with separate compilation unless
> >> > the parameter names were mangled into the function names,
> >> > and symbol names in D are already too often too long due to
> >> > idioms like Voldemort types creating really long symbol
> >> > names. Recent work on the compiler has reduced that problem,
> >> > but adding more information to mangled names would
> >> > definitely not help.
> >>
> >> [...]
> >>
> >> Nah.  Parameter names are a concept only necessary at
> >> compile-time.  All you need is to import the function
> >> declaration with the right parameter names, and on the
> >> caller's side the compiler will always emit the arguments in
> >> the right order.  So no need to mangle parameter names at all.
> >
> > Except that things get a bit interesting with regards to stuff
> > like .di files. Without the parameter names being mangled in,
> > it would be possible for the parameter names in the .di files
> > to not match the ones in the .d files. It's possible for that
> > now, but right now, it doesn't matter, whereas with named
> > arguments, it would matter. To some extent, you could probably
> > get away with it, because the code that compiles against the
> > .di files wouldn't normally be compiled against the .d files or
> > vice versa, but it means that switching whether you used the
> > .di files or the .d files could break code, whereas now, it
> > wouldn't.
> >
> > Now, .di files are kind of terrible to use anyway, but
> > introducing named arguments would just make them even more
> > fragile if the parameter names aren't part of the function's
> > mangled name.
> >
> > - Jonathan M Davis
>
> Pardon me, but I don't understand how named arguments can break
> anything by being added, as long as you don't add an additional
> syntax to the function declaration.
>
> void foo(int bar, int baz)
> {
> }
>
> in .di
>
> void foo(int bar, int baz);
>
> ...
>
> Can be called like:
>
> foo(1, 2);
>
> foo(bar: 1, baz: 2); becomes foo(1, 2);
>
> foo(baz: 2, bar: 1); becomes foo(1, 2); because it matches the
> argument index.
>
> int bar = 1;
> int baz = 2;
> foo(bar, baz);

The issue I'm talking about is that if we had named arguments, and the names
of the parameters in .di and .d files didn't match, and named arguments
were used, then changing whether the .di file or .d file were used would
break code. e.g.

.di:

void foo(int a, int b);

.d:

void foo(int c, int d);

Then this code

foo(a : 4, b : 7);

would compile with the .di file but not the .d file. That's not the end of
the world, but it makes .di files even more fragile than they already are.

Adding named parameters would not break any existing code, but it would
introduce more ways to break code. Right now, no code anywhere has to care
about parameter names except the function that has those parameters. There
is no dependency on those names. You don't even have to have parameter names
in a .di file if you don't want to - all that matters is the types. A
function's parameter names can be changed at any time without breaking _any_
code that calls that function. But as soon as we have named arguments,
suddenly, you can't change parameter names anymore than you can change the
name of a function, or you risk breaking code, and that's a _huge_ negative
IMHO. It also means more bikeshedding over names, because suddenly the
parameter names are part of the API. It's even worse when you consider that
most parameter names in existing code were not chosen with the idea that
they would be part of the function's API, because we don't currently have
named arguments in D.

IMHO, it's already annoying enough how locked down things are once you put
them out in the wild for others to use (at least if you care about not
breaking the code of anyone using any code you make available). I don't want
to see yet more added to the list of things that you can't change, because
it might break someone's code, and adding named arguments to D definitely
would do that, because it would make the parameter names part of the API,
which they're not right now.

- Jonathan M Davis