On Mon, Feb 10, 2020 at 1:05 PM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 10 February 2020 at 20:45:22 UTC, Manu wrote:
> > On Mon, Feb 10, 2020 at 11:50 AM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On Monday, 10 February 2020 at 19:38:34 UTC, Manu wrote:
> >> > On Thu, Feb 6, 2020 at 7:34 PM Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >> >> [...]
> >> >
> >> > I don't have any horse in this race... but I do just want to
> >> > echo that
> >> > I don't understand this feature at all.
> >> > I don't know what it's for. I've never felt I wanted named
> >> > arguments
> >> > personally, and Jonathan's criticism feels very real to me.
> >> >
> >> > [...]
> >>
> >> For me personalty, readability\reliability is a huge factor here. Knowing what values should go to where is a big plus for me, when dealing with default arguments. I work with C# code when it comes to web development, and the default parameters prevent me sending values to the wrong parameter.
> >>
> >> -Alex
> >
> > That feels like a pretty washy justification.
> Manu, it boils down to mainly experience when it comes to wanting named arguments. I have argue in favor of them in the past already in other DIP. I have no interest of repeating them.

I've seen some arguments, but I haven't understood them personally. I
don't have a feel for their value, I can't judge that.
I have described an important material loss associated with this. I'd
like to see that important issue addressed in the form of "use this
pattern instead" or, "we accept we are abandoning that important
pattern, we feel it was less important than this DIP, and we accept
code that uses that pattern will be broken", which, incidentally, is
almost all D code I've ever written in a professional capacity... :/

I also have a fear that where making parameter names part of the API;
renaming parameter == breaking change, this feels bad to me. It's
resistant to improving API clarity over time.
In my experience, API clarity is an ongoing maintenance challenge,
where your poor choice in names is only discovered some time later as
you have experience with other humans sense of intuition differing
from your own initial judgement.
That argument is about equally washy as your core argument, except
from my personal point of view, I know that my argument here
absolutely applies to me frequently over decades of experience, while
I've never wanted names arguments once; so weighing the value
judgement in that particular compromise seems obvious to me.

On Monday, 10 February 2020 at 21:17:45 UTC, Manu wrote:
> On Mon, Feb 10, 2020 at 1:05 PM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On Monday, 10 February 2020 at 20:45:22 UTC, Manu wrote:
>> > On Mon, Feb 10, 2020 at 11:50 AM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> >>
>> >> On Monday, 10 February 2020 at 19:38:34 UTC, Manu wrote:
>> >> > On Thu, Feb 6, 2020 at 7:34 PM Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> >> >> [...]
>> >> >
>> >> > I don't have any horse in this race... but I do just want to
>> >> > echo that
>> >> > I don't understand this feature at all.
>> >> > I don't know what it's for. I've never felt I wanted named
>> >> > arguments
>> >> > personally, and Jonathan's criticism feels very real to me.
>> >> >
>> >> > [...]
>> >>
>> >> For me personalty, readability\reliability is a huge factor here. Knowing what values should go to where is a big plus for me, when dealing with default arguments. I work with C# code when it comes to web development, and the default parameters prevent me sending values to the wrong parameter.
>> >>
>> >> -Alex
>> >
>> > That feels like a pretty washy justification.
>> Manu, it boils down to mainly experience when it comes to wanting named arguments. I have argue in favor of them in the past already in other DIP. I have no interest of repeating them.
>
> I've seen some arguments, but I haven't understood them personally. I
> don't have a feel for their value, I can't judge that.
> I have described an important material loss associated with this. I'd
> like to see that important issue addressed in the form of "use this
> pattern instead" or, "we accept we are abandoning that important
> pattern, we feel it was less important than this DIP, and we accept
> code that uses that pattern will be broken", which, incidentally, is
> almost all D code I've ever written in a professional capacity... :/
>
> I also have a fear that where making parameter names part of the API;
> renaming parameter == breaking change, this feels bad to me. It's
> resistant to improving API clarity over time.
> In my experience, API clarity is an ongoing maintenance challenge,
> where your poor choice in names is only discovered some time later as
> you have experience with other humans sense of intuition differing
> from your own initial judgement.
> That argument is about equally washy as your core argument, except
> from my personal point of view, I know that my argument here
> absolutely applies to me frequently over decades of experience, while
> I've never wanted names arguments once; so weighing the value
> judgement in that particular compromise seems obvious to me.

Yes, I have encounter the "API breakage" counter argument in other threads already. Still not convinced that it is a big issue as they make it out to be.

On Mon, Feb 10, 2020 at 1:30 PM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 10 February 2020 at 21:17:45 UTC, Manu wrote:
> > On Mon, Feb 10, 2020 at 1:05 PM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On Monday, 10 February 2020 at 20:45:22 UTC, Manu wrote:
> >> > On Mon, Feb 10, 2020 at 11:50 AM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >> >>
> >> >> On Monday, 10 February 2020 at 19:38:34 UTC, Manu wrote:
> >> >> > On Thu, Feb 6, 2020 at 7:34 PM Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >> >> >> [...]
> >> >> >
> >> >> > I don't have any horse in this race... but I do just want
> >> >> > to
> >> >> > echo that
> >> >> > I don't understand this feature at all.
> >> >> > I don't know what it's for. I've never felt I wanted named
> >> >> > arguments
> >> >> > personally, and Jonathan's criticism feels very real to
> >> >> > me.
> >> >> >
> >> >> > [...]
> >> >>
> >> >> For me personalty, readability\reliability is a huge factor here. Knowing what values should go to where is a big plus for me, when dealing with default arguments. I work with C# code when it comes to web development, and the default parameters prevent me sending values to the wrong parameter.
> >> >>
> >> >> -Alex
> >> >
> >> > That feels like a pretty washy justification.
> >> Manu, it boils down to mainly experience when it comes to wanting named arguments. I have argue in favor of them in the past already in other DIP. I have no interest of repeating them.
> >
> > I've seen some arguments, but I haven't understood them
> > personally. I
> > don't have a feel for their value, I can't judge that.
> > I have described an important material loss associated with
> > this. I'd
> > like to see that important issue addressed in the form of "use
> > this
> > pattern instead" or, "we accept we are abandoning that important
> > pattern, we feel it was less important than this DIP, and we
> > accept
> > code that uses that pattern will be broken", which,
> > incidentally, is
> > almost all D code I've ever written in a professional
> > capacity... :/
> >
> > I also have a fear that where making parameter names part of
> > the API;
> > renaming parameter == breaking change, this feels bad to me.
> > It's
> > resistant to improving API clarity over time.
> > In my experience, API clarity is an ongoing maintenance
> > challenge,
> > where your poor choice in names is only discovered some time
> > later as
> > you have experience with other humans sense of intuition
> > differing
> > from your own initial judgement.
> > That argument is about equally washy as your core argument,
> > except
> > from my personal point of view, I know that my argument here
> > absolutely applies to me frequently over decades of experience,
> > while
> > I've never wanted names arguments once; so weighing the value
> > judgement in that particular compromise seems obvious to me.
>
> Yes, I have encounter the "API breakage" counter argument in other threads already. Still not convinced that it is a big issue as they make it out to be.

It's a huge problem today when a bad choice of function name is
calcified; we'll be multiplying the probability of making bad naming
choices by 2-3x.
We can correct a bad function name by renaming it and producing a
deprecated alias for the old name. We have no such way to correct a
change in parameter name; we can't use alias because the parameter
names are not part of the signature.

Don't ignore the material issue I've shown that demands one of the 2
responses I suggested.
If you push for acceptable of this DIP, then I think you must have a
response to my primary issue.

On Monday, 10 February 2020 at 21:41:02 UTC, Manu wrote:
> [snip]
>
> It's a huge problem today when a bad choice of function name is
> calcified; we'll be multiplying the probability of making bad naming
> choices by 2-3x.
> We can correct a bad function name by renaming it and producing a
> deprecated alias for the old name. We have no such way to correct a
> change in parameter name; we can't use alias because the parameter
> names are not part of the signature.
>
> Don't ignore the material issue I've shown that demands one of the 2
> responses I suggested.
> If you push for acceptable of this DIP, then I think you must have a
> response to my primary issue.

I was leaning towards favoring this DIP, as I frequently use named arguments in R and like the flexibility they offer in some cases. However, I came across two functions, written in python, at work. One takes a parameter and the other takes a slightly different parameter name. No good reason why these two do not use the same parameter names. They should be the same. However, python has named arguments for everything, so changing the names would mean that any code that uses the named version breaks. It definitely would make people much more conservative about changing their functions.

On Monday, 10 February 2020 at 21:41:02 UTC, Manu wrote:
> On Mon, Feb 10, 2020 at 1:30 PM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On Monday, 10 February 2020 at 21:17:45 UTC, Manu wrote:
>> > On Mon, Feb 10, 2020 at 1:05 PM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> >>
>> >> On Monday, 10 February 2020 at 20:45:22 UTC, Manu wrote:
>> >> > On Mon, Feb 10, 2020 at 11:50 AM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> >> >>
>> >> >> On Monday, 10 February 2020 at 19:38:34 UTC, Manu wrote:
>> >> >> > On Thu, Feb 6, 2020 at 7:34 PM Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> >> >> >> [...]
>> >> >> >
>> >> >> > I don't have any horse in this race... but I do just want
>> >> >> > to
>> >> >> > echo that
>> >> >> > I don't understand this feature at all.
>> >> >> > I don't know what it's for. I've never felt I wanted named
>> >> >> > arguments
>> >> >> > personally, and Jonathan's criticism feels very real to
>> >> >> > me.
>> >> >> >
>> >> >> > [...]
>> >> >>
>> >> >> For me personalty, readability\reliability is a huge factor here. Knowing what values should go to where is a big plus for me, when dealing with default arguments. I work with C# code when it comes to web development, and the default parameters prevent me sending values to the wrong parameter.
>> >> >>
>> >> >> -Alex
>> >> >
>> >> > That feels like a pretty washy justification.
>> >> Manu, it boils down to mainly experience when it comes to wanting named arguments. I have argue in favor of them in the past already in other DIP. I have no interest of repeating them.
>> >
>> > I've seen some arguments, but I haven't understood them
>> > personally. I
>> > don't have a feel for their value, I can't judge that.
>> > I have described an important material loss associated with
>> > this. I'd
>> > like to see that important issue addressed in the form of "use
>> > this
>> > pattern instead" or, "we accept we are abandoning that important
>> > pattern, we feel it was less important than this DIP, and we
>> > accept
>> > code that uses that pattern will be broken", which,
>> > incidentally, is
>> > almost all D code I've ever written in a professional
>> > capacity... :/
>> >
>> > I also have a fear that where making parameter names part of
>> > the API;
>> > renaming parameter == breaking change, this feels bad to me.
>> > It's
>> > resistant to improving API clarity over time.
>> > In my experience, API clarity is an ongoing maintenance
>> > challenge,
>> > where your poor choice in names is only discovered some time
>> > later as
>> > you have experience with other humans sense of intuition
>> > differing
>> > from your own initial judgement.
>> > That argument is about equally washy as your core argument,
>> > except
>> > from my personal point of view, I know that my argument here
>> > absolutely applies to me frequently over decades of experience,
>> > while
>> > I've never wanted names arguments once; so weighing the value
>> > judgement in that particular compromise seems obvious to me.
>>
>> Yes, I have encounter the "API breakage" counter argument in other threads already. Still not convinced that it is a big issue as they make it out to be.
>
> It's a huge problem today when a bad choice of function name is
> calcified; we'll be multiplying the probability of making bad naming
> choices by 2-3x.
Which is a no big deal when the probability is very low to big with. Besides I don't need to justified it to you when are not the person who I need to be convinced in order for the dip to be accepted.

We literally have two named arguments DIP that are postponed for this DIP. The discussion has been made so many times already in which your concerns and objections has brought up time and time again. Which frankly I don't have time nor the energy to argue in favor it again when you can look into those discussions threads already.

There is no apocalypse scenario in C# community, when it comes to named arguments.

-Alex

On Monday, 10 February 2020 at 20:50:40 UTC, Manu wrote:
> Not being able to easily produce call shims or wrappers is a huge loss without some sort of solution analogous to existing reflection tools.

This does not occur.

On Monday, 10 February 2020 at 21:54:53 UTC, jmh530 wrote:
> However, python has named arguments for everything, so changing the names would mean that any code that uses the named version breaks. It definitely would make people much more conservative about changing their functions.

In Python it is different because there's no compiler to tell you where changes occur.

In D, this is the most trivial type of breakage - the compiler tells you where the change is and can make a good guess as to what the fix is too and can suggest it.

It is a slight hassle - I remember renaming of functions in std.string driving me nuts in D ~2012ish. But it never *broke* my code per se, it wasn't something throwing at runtime when it didn't before, it was just an annoying half hour of find/replace tedium when I chose to update. (and note an option was just to defer the update too)

And now the names are legit better.

Like I said earlier in the thread, I can see a middle-man wanting compatibility across versions being a maybe, and we could do a deprecated alias for that, but I doubt it will be that hard. Consider it a minor version bump and - in theory - updates should be easy enough to schedule and do that tedious find/replace.

On Thursday, 6 February 2020 at 06:08:59 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1030, "Named Arguments":
>
> https://github.com/dlang/DIPs/blob/44b0d4ec0da6a2e797ede748fb1e81cd6db10371/DIPs/DIP1030.md
>
> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits... in other words, business as usual.
>
> However, if you have any specific feedback for how to improve the the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> The review period will end at 11:59 PM ET on February 20, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Please stay on topic here. I will delete posts that are completely off topic.

I'm curious what the current state of druntime/phobos is with parameter name consistency.
 I took a quick look at std.math in phobos to see what some of the current argument names are:

auto conj(Num)(Num z) @safe pure nothrow @nogc
auto abs(Num)(Num x) @nogc pure nothrow
real cos(real x) @safe pure nothrow @nogc { pragma(inline, true); return core.math.cos(x); }
auto sin(creal z) @safe pure nothrow @nogc
auto sin(ireal y) @safe pure nothrow @nogc

So we have some of this:

conj(z:someValue);
abs(x:someValue);
sin(y:someValue);

Now that parameter names are apart of the function's API, this inconsistency starts to matter as changing it breaks the API.  Will druntime/phobos try to come up with standard names for these situations?  Will we try to fix these names before integrating support for named parameters?  If we need to change names later, what will the policy be for druntime/phobos for making parameter name changes when inconsistencies are discovered?

Also consider the case when overloads use different parameter names.  std.math.sin uses 'z' for creal arguments and 'y' for ireal arguments.  This can cause issues during refactor as one needs to re-check all parameter names when changing types of arguments. i.e.

sin(z:someValue);

If you change the type of someValue from creal to ireal, then this would still call the creal overload, perhaps unexpectedly.

On Mon, Feb 10, 2020 at 1:55 PM jmh530 via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 10 February 2020 at 21:41:02 UTC, Manu wrote:
> > [snip]
> >
> > It's a huge problem today when a bad choice of function name is
> > calcified; we'll be multiplying the probability of making bad
> > naming
> > choices by 2-3x.
> > We can correct a bad function name by renaming it and producing
> > a
> > deprecated alias for the old name. We have no such way to
> > correct a
> > change in parameter name; we can't use alias because the
> > parameter
> > names are not part of the signature.
> >
> > Don't ignore the material issue I've shown that demands one of
> > the 2
> > responses I suggested.
> > If you push for acceptable of this DIP, then I think you must
> > have a
> > response to my primary issue.
>
> I was leaning towards favoring this DIP, as I frequently use named arguments in R and like the flexibility they offer in some cases. However, I came across two functions, written in python, at work. One takes a parameter and the other takes a slightly different parameter name. No good reason why these two do not use the same parameter names. They should be the same. However, python has named arguments for everything, so changing the names would mean that any code that uses the named version breaks. It definitely would make people much more conservative about changing their functions.

We deprecate and rename things all the time. If this DIP is accepted, I think it would be the case that we need a working pattern to deprecate argument names the same as we can with function names today. We can't use alias, because names are not part of the signature. We can't use overloads as backwards-compatibility wrappers, because they're ambiguous calls (again, because names are not pert of the signature).

Calcification of API will increase. Poor name choices will be cemented in.


On Mon, Feb 10, 2020 at 2:00 PM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 10 February 2020 at 21:41:02 UTC, Manu wrote:
> > It's a huge problem today when a bad choice of function name is
> > calcified; we'll be multiplying the probability of making bad
> > naming
> > choices by 2-3x.
>
> Which is a no big deal when the probability is very low to big with.

Ummm... you're saying bad API names has a "very low probability"? Finish this sentence: "There are 2 hard problems in computer science..."

I mean, I'm constantly tweaking API's for intuitive appeal. Programmers do this _all the time_.

> We literally have two named arguments DIP that are postponed for this DIP. The discussion has been made so many times already in which your concerns and objections has brought up time and time again. Which frankly I don't have time nor the energy to argue in favor it again when you can look into those discussions threads already.

I've never posted a single comment in a named argument thread. It's
just not a thing I care about.
I commented today because I feel like this DIP has a high probability
of acceptance (because Walter wrote it), and I wanted to understand
what was about to happen.

I'm still mostly ambivalent about this, but I'm concerned you're still
carefully avoiding my key concern; I showed an entire class of code
that will be broken, you need to have a response to that.
Basically everything I've ever written in a professional capacity will
cease working if clients can call with named arguments.

> There is no apocalypse scenario in C# community, when it comes to named arguments.

They didn't have a decade of existing and important code that will break.
I think accepting this DIP must be coupled with a recommended pattern
to address the code I described, because it will be broken, and must
be migrated.


On Mon, Feb 10, 2020 at 2:10 PM Adam D. Ruppe via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 10 February 2020 at 20:50:40 UTC, Manu wrote:
> > Not being able to easily produce call shims or wrappers is a huge loss without some sort of solution analogous to existing reflection tools.
>
> This does not occur.

I don't understand... ?

On Monday, 10 February 2020 at 23:20:34 UTC, Jonathan Marler wrote:
> On Thursday, 6 February 2020 at 06:08:59 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1030, "Named Arguments":
>>
>> https://github.com/dlang/DIPs/blob/44b0d4ec0da6a2e797ede748fb1e81cd6db10371/DIPs/DIP1030.md
>>
>> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits... in other words, business as usual.
>>
>> However, if you have any specific feedback for how to improve the the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:
>>
>> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>>
>> The review period will end at 11:59 PM ET on February 20, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>>
>> Please stay on topic here. I will delete posts that are completely off topic.
>
> I'm curious what the current state of druntime/phobos is with parameter name consistency.
>  I took a quick look at std.math in phobos to see what some of the current argument names are:
>
> auto conj(Num)(Num z) @safe pure nothrow @nogc
> auto abs(Num)(Num x) @nogc pure nothrow
> real cos(real x) @safe pure nothrow @nogc { pragma(inline, true); return core.math.cos(x); }
> auto sin(creal z) @safe pure nothrow @nogc
> auto sin(ireal y) @safe pure nothrow @nogc
>
> So we have some of this:
>
> conj(z:someValue);
> abs(x:someValue);
> sin(y:someValue);
>
> Now that parameter names are apart of the function's API, this inconsistency starts to matter as changing it breaks the API.  Will druntime/phobos try to come up with standard names for these situations?  Will we try to fix these names before integrating support for named parameters?  If we need to change names later, what will the policy be for druntime/phobos for making parameter name changes when inconsistencies are discovered?
>
> Also consider the case when overloads use different parameter names.  std.math.sin uses 'z' for creal arguments and 'y' for ireal arguments.  This can cause issues during refactor as one needs to re-check all parameter names when changing types of arguments. i.e.
>
> sin(z:someValue);
>
> If you change the type of someValue from creal to ireal, then this would still call the creal overload, perhaps unexpectedly.

I took some time to go through the "std.array" module to see how many potential issues it might have.  Here's what I saw:



-------------------------------------------------------------------------------
different overloads of split use different parameter names
-------------------------------------------------------------------------------

> S[] split(S)(S s) @safe pure
> auto split(alias isTerminator, Range)(Range range)
> auto split(Range, Separator)(Range range, Separator sep)

split(s: value);
split(range: value);

-------------------------------------------------------------------------------
different overloads of "array" use different parameter names
-------------------------------------------------------------------------------

> ForeachType!Range[] array(Range)(Range r)
> ForeachType!(PointerTarget!Range)[] array(Range)(Range r)
> CopyTypeQualifiers!(ElementType!String,dchar)[] array(String)(scope String str)

array(r: value);
array(str: value);

-------------------------------------------------------------------------------
Generic Range parameters use many different names 'r', 'range', 'ror', 'stuff', 's'
-------------------------------------------------------------------------------
> auto split(alias isTerminator, Range)(Range range)
> ForeachType!Range[] array(Range)(Range r)
> ForeachType!(PointerTarget!Range)[] array(Range)(Range r)
> ElementEncodingType!(ElementType!RoR)[] join(RoR, R)(RoR ror, scope R sep)
> ElementEncodingType!(ElementType!RoR)[] join(RoR, E)(RoR ror, scope E sep)
> ElementEncodingType!(ElementType!RoR)[] join(RoR)(RoR ror)
> T[] replace(T, Range)(T[] subject, size_t from, size_t to, Range stuff)
> ElementType!S[] replicate(S)(S s, size_t n)

split(r: value);
array(range: value);
join(ror: value);
replace(subject: value1, from: value2, to: value3, stuff: value4);
replicate(s: value, n: 100);

-------------------------------------------------------------------------------
functions that take 2 arguments but have different parameter names
-------------------------------------------------------------------------------
> CommonType!(T[], U[]) overlap(T, U)(T[] a, U[] b) @trusted
> pure nothrow bool sameHead(T)(in T[] lhs, in T[] rhs)
> pure nothrow bool sameTail(T)(in T[] lhs, in T[] rhs)

overlay(a: value1, b: value2);
sameHead(lhs: value1, rhs: value2);

-------------------------------------------------------------------------------
sometimes an array is passed with 'a', sometimes with 'array', sometimes 'arr'
-------------------------------------------------------------------------------
> void insertInPlace(T, U...)(ref T[] array, size_t pos, U stuff)
> auto staticArray(size_t n, T)(scope T a)
> auto staticArray(size_t n, T)(scope T a, out size_t rangeLength)
> Appender!(E[]) appender(A : E[], E)(auto ref A array)
> RefAppender!(E[]) appender(P : E[]*, E)(P arrayPtr)
> struct Appender(A)
>     this(A arr) @trusted pure nothrow

insertInPlace(array: value1, pos: value2, stuff: value3);
staticArray(a: value);
Appender(arr: value);

-------------------------------------------------------------------------------
Appender functions use inconsistent parameter names
-------------------------------------------------------------------------------
> struct Appender(A)
>     void reserve(size_t newCapacity)
>     private void ensureAddable(size_t nelems)

appender.reserve(newCapacity: value);
appender.ensureAddable(nelems: value);

-------------------------------------------------------------------------------
Sometimes "length" is spelled out, sometimes it is abbreviated to "len"
-------------------------------------------------------------------------------
> auto staticArray(size_t n, T)(scope T a, out size_t rangeLength)
> private size_t appenderNewCapacity(size_t TSizeOf)(size_t curLen, size_t reqLen) @safe pure nothrow

staticArray(a: value, rangeLength: value2);
appenderNewCapacity(curLen: 100, reqLen: 200);

-------------------------------------------------------------------------------
appender overloads use different parameter names
-------------------------------------------------------------------------------
> Appender!(E[]) appender(A : E[], E)(auto ref A array)
> RefAppender!(E[]) appender(P : E[]*, E)(P arrayPtr)

appender(array: value);
appender(arrayPtr: value);