preparing for named arguments

[Jonathan M Davis]

On Tuesday, August 27, 2019 9:10:12 AM MDT Kagamin via Digitalmars-d wrote:
> On Monday, 26 August 2019 at 23:46:51 UTC, Jonathan M Davis wrote:
> > 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.
>
> Well, they are in the docs? So inconsistency is already exposed.
> But if current naming is reasonable, then renaming is not needed.

The documentation doesn't need to have consistent names for parameters. As
far as docs go, the names are really only needed so that you can easily
connect the description of each parameter with the correct parameter, and if
the names are reasonable, then it's fine. Whether a range parameter is named
is r, range, source, haystack, or whatever really doesn't matter for
documentation. However, if people start actually typing the names of any of
the parameters in their own code because of named arguments, then suddenly,
it becomes a problem if the names are inconsistent. There's pretty much no
way that folks are going to be able to remember which functions use r and
which use range - or use a different name entirely. Right now, that don't
need to remember or care, but if we had named arguments, that would change.

- Jonathan M Davis