DIP 1020--Named Parameters--Community Review Round 1

[Paul Backus]

On 4/9/19 5:20 PM, aliak wrote:
> It's worth considering allowing API authors to control how their APIs
> ought to be called. I've never completely understood why reordering is a
> requirement for some from the caller's side. It doesn't really add
> anything in terms of readability or maintainability in my experience -
> in-fact it reduces them because consistency goes out the window. And I'm
> not sure how allowing all parameters to be called as named is going to
> help in anyway other than making API authors' lives harder in terms of
> maintenance costs:
> 

If you have named arguments, and allow skipping over optional arguments,
but *don't* allow reordering, you end up with some really silly-looking
errors:

// One of these calls will fail to compile
spawnProcess("./do_stuff", stdout: outputFile, stderr: logFile);

// This doesn't, because 'stdout' comes before 'stderr'
spawnProcess("./do_stuff", stderr: logFile, stdout: outputFile);

Would you rather (a) have to explain to new D users why the first one
works and the second one doesn't, or (b) live with parameter reordering
being allowed?