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

Jonathan M Davis newsgroup.d at jmdavisprog.com
Thu Jun 6 21:46:14 UTC 2019


On Thursday, June 6, 2019 1:50:09 PM MDT FeepingCreature via Digitalmars-d 
wrote:
> On Thursday, 6 June 2019 at 19:17:38 UTC, Jonathan Marler wrote:
> > There's a big issue with this DIP.  It immediately allows any
> > function call to increase coupling with the corresponding
> > function definition with no way to disable it.
>
> I just want to explicitly note that increasing coupling between
> the call site and the function definition is the entire point of
> named parameters.

Which is precisely why I really hope that no named parameter DIP is ever
accepted. It means that suddenly the parameter names are part of the API,
meaning that there's yet another point where you have to worry about
breaking user code and another point where you have to worry about naming
things really well and where people will then bikeshed names. E.G. right
now, there is zero attempt in Phobos to name all range parameters the same,
and there's no need to, but if named parameters become a thing (especially
without requiring that the function be annotated to allow them), then
suddenly, we have naming problems all over the place when we didn't before,
because the naming isn't consistent.

IMHO, named parameters are rarely useful with well-written code. They're
primarily of benefit when you have a lot of function parameters, which is
bad design. And they're a particularly odd design choice in a language where
you're allowed to have interface files that don't even have to provide
parameter names let alone make them match the ones in the .d file.

But I suppose that there isn't much point in my expressing how much I hate
DIPs like this in review threads, since such threads are really just for
helping to improve the DIP, not vote it down. The decision on that is solely
up to Walter and Andrei (or Atila now, I guess).

- Jonathan M Davis





More information about the Digitalmars-d mailing list