DIP 1019--Named Arguments Lite--Community Review Round 1

[Jonathan M Davis]

On Friday, February 15, 2019 5:56:45 AM MST Mike Parker via Digitalmars-d 
wrote:
> This is the feedback thread for the first round of Community
> Review for DIP 1019, "Named Arguments Lite":
>
> https://github.com/dlang/DIPs/blob/23ef47a94e0fdd5ddc4b2f6b2f4dcfd3c1f43aa
> 6/DIPs/DIP1019.md
>
> All review-related feedback on and discussion of the DIP should
> occur in this thread. The review period will end at 11:59 PM ET
> on March 1, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the
> DIP will be scheduled for another round of Community Review.
> Otherwise, it will be queued for the Final Review and Formal
> Assessment by the language maintainers.
>
> Please familiarize yourself with the documentation for the
> Community Review before participating.
>
> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review
>
> Thanks in advance to all who participate.

I honestly don't understand the whole deal about discussing "repurposing"
function parameters. If you refactor a function, it needs to continue to
work with all existing calls to it, or it's going to break code. So, stuff
like swapping x and y and the like make absolutely no sense. If you're going
to screw up existing function calls by changing the function's signature,
then you can't change the function's signature. So, I don't see any point in
even worrying about function parameters being repurposed.

Personally, I hope that we never have any form of named arguments in D
(beyond whatever folks do with libraries, though I hope never have to deal
with code that uses such libraries). But ultimately, that's going to be up
to Walter and Andrei...

I do approve of the fact that this DIP doesn't automatically enable named
arguments everywhere, since I really, really, really don't want to have
parameters be part of the API if I can possibly avoid it, and I would never
use @named anywhere if this DIP gets approved - though in all likelihood,
that will result in arguments about whether folks should slap @named on
functions or not between folks who want named arguments and those who don't.
So, approval of the DIP with such an attribute could become pretty divisive
with regards to how folks write libraries.

I'm not sure that you can punt the name mangling issue like the DIP
currently does. It's currently legal to declare functions without even
having parameter names (let alone requiring that the parameter names match)
when you deal with stuff like .di files. It also affects what happens with
functions that aren't extern(D). For instance, it's perfectly legal to put
pure or nothrow on an extern(C) function declaration, and that affecs how
the D code uses it, but it has no effect on the name mangling. If named
arguments affect the name mangling, then they will only work with extern(D)
functions, but if they don't, then you have issues when a function's
declaration doesn't match its definition with regards to its parameters'
names.

- Jonathan M Davis