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

[Joseph Rushton Wakeling]

On Thursday, 28 February 2019 at 08:32:22 UTC, FeepingCreature 
wrote:
> Yes it does!! That is in fact the main argument for it! It 
> allows the compiler to do a *much* better job at ensuring the 
> correctness of programs, by attaching parameters to semantic 
> labels instead of passing them by arbitrary positions and 
> hoping that the type system will happen to catch errors.

This could sometimes be nice, but the question is whether the 
extra benefits are worth it compared to the problems caused by 
imposing a major semantic change on the language.

> If a new parameter is added to Config, there is *absolutely* no 
> way to require it to be passed. You have to use something like 
> my own `boilerplate.Builder()`, and even that just gives you an 
> exception at compiletime.
>
> [... snip ...]
>
> There is *no way* to statically enforce that a field was set in 
> a struct.

That's certainly a reasonable objection.  The question is not, 
does this cover _all_ use cases for named parameters, but does it 
cover some of the major ones that matter?  (For example, the case 
of multiple different parameters where one only wants to set the 
ones that need to be non-default.)

> Parameters on the other hand do this effortlessly. I'd *love* 
> to ditch Boilerplate's generated builders and replace them with 
> named parameters. The lack of named parameters is why that 
> hacky expensive feature even exists to begin with.

I'm not familiar with your Boilerplate library, so difficult to 
comment -- are you saying here that the library's features could 
be implemented more straightforwardly (or with a nicer API for 
users) if named parameters were a thing?  Or that features of the 
library would not need to exist in the first place?

I ask because it's possible that the requirements here are 
arriving more out of preferences for how to write the downstream 
code, than about problems with writing idiomatically in D as it 
is right now.

> I have literally never done that, whereas I reorder function 
> parameters relatively often. Do you really rename function 
> parameters more often than inserting a new required parameter 
> in the middle?

In what context do you reorder or insert new function parameters 
often?  In public functions or methods of a library?  In 
internals private to a library or app?  And what's the motivation 
for such re-ordering?

I ask because I wonder if there aren't other entirely adequate 
methods for managing those transitions that don't rely on named 
parameters, and which are more idiomatic to D as it already 
exists.  If you have concrete examples we could probably discuss 
those.

I accept that named parameters might make some of these 
transitions easier, but that has to be weighed against the 
disruption of introducing that feature to a language where a 
large amount of code has already been written without that 
feature in mind.