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.

I think that named arguments emerged long time ago because of Windows API. :)

Do you remember those functions calls with lots of parameters to fill?

But like you said I think today it's a bad design. I program in C# too and barely use this feature because I try to make things sane.

Matheus.

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.

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

On Tuesday, 27 August 2019 at 15:30:29 UTC, Jonathan M Davis wrote:
> 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

Parameter names should be more than single letters, for the same reasons they shouldn't be single letters as variables and function names. If you are looking at two overloads, and they both just name their parameters after letters. It takes more time to go and read the documentation, rather than being able to differentiate the two based on their parameter names.

I remember looking at some of the many bindings to C libraries, either Posix, Windows, or Stdlib for C. Someone, out of the goodness of their heart decided it was a good idea to name the parameters "a", "b", "c". Thankfully D does not provide documentation for bindings to C functions either. Triple whammy. Instead of just getting the information as I was typing the function (with auto complete) for the parameters names. I had to go to the definition to see the documentation and spend extra time reading it. Just to find out there was no documentation for it. Then having to go and search the actual documentation for it externally. I guess it just speaks to immaturity of the standard library for phobos, where there are many instances of parameters just being single characters (including for bindings with no documentation) and (no less) there are people arguing for it that it is fine.

On Wednesday, 28 August 2019 at 04:13:06 UTC, Exil wrote:
>
> Parameter names should be more than single letters, for the same reasons they shouldn't be single letters as variables and function names. If you are looking at two overloads, and they both just name their parameters after letters. It takes more time to go and read the documentation, rather than being able to differentiate the two based on their parameter names.
>
> I remember looking at some of the many bindings to C libraries, either Posix, Windows, or Stdlib for C. Someone, out of the goodness of their heart decided it was a good idea to name the parameters "a", "b", "c". Thankfully D does not provide documentation for bindings to C functions either. Triple whammy. Instead of just getting the information as I was typing the function (with auto complete) for the parameters names. I had to go to the definition to see the documentation and spend extra time reading it. Just to find out there was no documentation for it. Then having to go and search the actual documentation for it externally. I guess it just speaks to immaturity of the standard library for phobos, where there are many instances of parameters just being single characters (including for bindings with no documentation) and (no less) there are people arguing for it that it is fine.

+1 to proper naming. it would be good to have consistent naming with the purpose of parameter/property/variable, not just for phobos, but for dmd too. Trying to make sense in dmd code sometimes is leading to scrolling up and down just to see what variables are for, then back at the usage point with knowledge of what they are (which is not clear in all cases), you've already forgot what the code using those variables is doing.