Discussion Thread: DIP 1030--Named Arguments--Final Review

Jonathan M Davis newsgroup.d at jmdavisprog.com
Fri May 15 19:56:56 UTC 2020


On Tuesday, May 12, 2020 6:37:51 PM MDT Walter Bright via Digitalmars-d wrote:
> We already have named arguments in D since the very beginning - the struct
> initialization syntax.
>
> Not a single person has complained about breakage when implementers changed
> the names of the struct fields.

I have _never_ used the struct initialization syntax, and I'm not sure that
I've ever actually seen it used in any code that I've worked on. In my
experience, it's also usually the case that structs aren't POD types and
don't expose their members, making it so that most structs wouldn't work
with the struct initialization syntax anyway (and I'm that much less likely
to have a POD struct in a library, because I don't want to have to deal with
worrying about breakage caused by name changes). I think that it's quite
safe to say that whatever impact struct initialization syntax has had is not
at all on the same level that named arguments would have.

Personally, I wish that the struct initialization syntax didn't exist in D,
but at least it seems to have relatively few people using it, whereas there
are enough people who seem to like the idea of named arguments that I expect
that once they're in, some people will start using them all over the place
like they were writing python rather than D.

> This is similar to:
>
> 1. what happens if the implementer changes the types of the parameters?
>
> 2. what happens if the implementer changes the order of the parameters?
>
> Then user code breaks.
>
> If anything, this feature will motivate implementers to take some care to
> name the parameters appropriately.

I don't want to have yet more stuff added to a function's API which I then
have to worry about whether I can change without breaking existing code. We
already have enough such problems to worry about without adding more. And I
don't want to have to deal with bikeshedding over parameter names like we
too often have to deal with with function names and type names. From the
perspective of someone writing libraries for others to use, I see named
arguments as nothing but trouble. And as a user, I don't see them as adding
any real benefit except in cases where functions have too many parameters
anyway and probably should have been designed differently.

Given that you're the one writing this DIP and that Atila has been in favor
of named arguments for years, I expect that I'm going to be stuck dealing
with named arguments in D at some point here, but I'm sure not happy about
the idea. It's a pythonism that IMHO just makes code worse - especially from
the perspective of having to worry about code breakage and bikeshedding. And
the fact that there are other things that you already have to worry about
breaking when changing function signatures doesn't mean that adding yet more
things that you have to worry about breaking isn't making things worse.

- Jonathan M Davis





More information about the Digitalmars-d mailing list