preparing for named arguments

Jonathan M Davis newsgroup.d at jmdavisprog.com
Mon Aug 26 23:46:51 UTC 2019


On Monday, August 26, 2019 4:19:38 PM MDT aliak via Digitalmars-d wrote:
> So Jonathan brought up a very good point against named arguments
> [0], that D is not consistent at all when it comes to argument
> names. E.g. range functions that have a parameter "r" as opposed
> to parameter "range" (and there're more).
>
> So if named arguments are accepted, from that release onwards
> people will start writing:
>
> choose(condition: true, r1: a, r2: b)
> radial(r: a);
> take(input: a, n: 3);
> takeExactly(range: a, n: 3);
> takeOne(source: a);
>
> There're probably a tonne of these with different parameter names
> for a range. It'll be a mess. And then any changes will be
> breaking.
>
> Should we maybe go through and make parameter names consistent
> where they obviously can be before named parameters gets to get
> in (should it get in)? e.g.:
>
> choose(condition: true, range1: a, range2: b)
> radial(range: a);
> take(range: a, n: 3);
> takeExactly(range: a, n: 3);
> takeOne(range: a);
>
> [0]
> https://forum.dlang.org/post/mailman.138.1566856133.19826.digitalmars-d@pu
> remagic.com

This is exactly one of the reasons why I think that named arguments are a
terrible idea. Now, we get to bikeshed about what the "official" name is
that we should be naming all of these range parameters in order to be
consistent and how we should deal with naming them when there are multiple
range arguments. None of this mattered previously. As long as the name was
reasonable, it was irrelevant, and even then, it really only mattered for
documentation purposes and for making the function internals reasonable to
maintain.

- Jonathan M Davis





More information about the Digitalmars-d mailing list