DIP 1019--Named Arguments Lite--Final Review

[Dennis]

On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu 
wrote:
> Large parameter lists of which most have reasonable defaults is 
> a marquee use case of named arguments. A proposal that works 
> itself out of that opportunity cannot and should not be 
> acceptable.

I'm personally not a fan of those argument lists the size of the 
Magna Cartas like you see in Python libraries:
https://matplotlib.org/3.1.1/api/_as_gen/matplotlib.lines.Line2D.html#matplotlib.lines.Line2D
I don't see it as a loss that this DIP doesn't enable those in D. 
If your function takes more than 6 arguments you should really 
consider creating a struct with configuration data.

On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu 
wrote:
> I was unconvinced by the argument that these can be added 
> later. Language design is peculiar in that incrementalism 
> doesn't work well - it must come all at once. There are 
> exceptions and arguments that can be made but there's 
> overwhelming evidence that incremental language design is just 
> not a good way to go about things.

In many cases (like the recent scope/@safe related proposals) I 
agree that implementing only part of a design has little value, 
but in this case the proposal has merits even in this limited 
form. Take for example this line:

glfwCreateWindow(1280, 720, "my window", null, null);

You can easily guess what the first three arguments are, but what 
about those two nulls? It could be made clearer like this:

glfwCreateWindow(1280, 720, "my window", fullScreenMonitor: null, 
parentWindow: null);

You can't leave `fullScreenMonitor` to the default while passing 
`parentWindow` with this DIP, but writing out that argument 
doesn't seem like a big loss to me. And even if it is, 
limitations can easily be lifted without much friction. If it 
turns out that reordering causes problems down the line, 
deprecating them would be more of a hassle.