www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - preparing for named arguments

reply aliak <something something.com> writes:
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 puremagic.com
Aug 26 2019
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Aug 26 2019
next sibling parent reply aliak <something something.com> writes:
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.


Yes I understand you don't want named parameters :) I think the 
benefits far outweigh this negative (plus I agree with rikki). 
But if they do go in without opt-in, then my question still 
stands?


 - Jonathan M Davis
Aug 27 2019
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, August 27, 2019 1:09:44 AM MDT aliak 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.


 Yes I understand you don't want named parameters :) I think the
 benefits far outweigh this negative (plus I agree with rikki).
 But if they do go in without opt-in, then my question still
 stands?


If we don't end up with named arguments in the language, then renaming the
parameters in Phobos is a waste of time and resources - not to mention a lot
of pointless bikeshedding over what the names should be. If we do get named
parameters, the DIP will almost certainly be accepted before anyone
implements the feature (potentially way before anyone implements it, since
DIPs that aren't implemented by the person proposing them tend to not be
implemented particularly quickly), so we can worry about renaming stuff
then.

- Jonathan M Davis
Aug 27 2019
parent aliak <something something.com> writes:
On Tuesday, 27 August 2019 at 07:35:32 UTC, Jonathan M Davis 
wrote:

 If we don't end up with named arguments in the language, then 
 renaming the parameters in Phobos is a waste of time and 
 resources - not to mention a lot of pointless bikeshedding over 
 what the names should be. If we do get named parameters, the 
 DIP will almost certainly be accepted before anyone implements 
 the feature (potentially way before anyone implements it, since 
 DIPs that aren't implemented by the person proposing them tend 
 to not be implemented particularly quickly), so we can worry 
 about renaming stuff then.

 - Jonathan M Davis


Fair enough.
Aug 27 2019
prev sibling next sibling parent matheus <matheus gmail.com> writes:
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 

sane.

Matheus.
Aug 27 2019
prev sibling parent reply Kagamin <spam here.lot> writes:
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.
Aug 27 2019
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Aug 27 2019
parent reply Exil <Exil gmall.com> writes:
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.
Aug 27 2019
parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
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.
Aug 28 2019
prev sibling next sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Mon, 26 Aug 2019 22:19:38 +0000, aliak wrote:

 
 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);


I can't see any place where I'd use the parameter name for a range, so r/
range/r1/etc. wouldn't matter. My range variable name is the 
documentation, or it's a literal array in a unittest. Based on what I've 
read of others' code, that's typical; and range functions tend to be small 
and named for what they do, so are self-documenting.

---
arr = myRange.sort!((a, b) => a > b)
    .takeExactly(10) // .takeExactly(number: 10) doesn't aid readability,
    .group           //  so why bother?
    .assocArray;
---

Most of the time in other languages a named parameter will document a 
literal argument or allow skipping parameters with default values. It 
would be a good idea to skim Phobos to name-check, but I don't think it 
will require a really large number of renames since most parameters 
realistically won't be passed via their names.

--Ryan
Aug 26 2019
parent aliak <something something.com> writes:
On Tuesday, 27 August 2019 at 02:09:55 UTC, rjframe wrote:

 On Mon, 26 Aug 2019 22:19:38 +0000, aliak wrote:

 [...]


 I can't see any place where I'd use the parameter name for a 
 range, so r/ range/r1/etc. wouldn't matter. My range variable 
 name is the documentation, or it's a literal array in a 
 unittest. Based on what I've read of others' code, that's 
 typical; and range functions tend to be small and named for 
 what they do, so are self-documenting.

 ---
 arr = myRange.sort!((a, b) => a > b)
     .takeExactly(10) // .takeExactly(number: 10) doesn't aid 
 readability,
     .group           //  so why bother?
     .assocArray;
 ---

 Most of the time in other languages a named parameter will 
 document a literal argument or allow skipping parameters with 
 default values. It would be a good idea to skim Phobos to 
 name-check, but I don't think it will require a really large 
 number of renames since most parameters realistically won't be 
 passed via their names.

 --Ryan


1) I agree about ranges, most will probably just use it in a way 
that it doesn't matter
2) But, if there's a feature it will be used. Always.
3) Won't hurt to make the arguments even for ranges consistent.
Aug 27 2019
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
This is a good example of why named arguments should be opt-in.
Unless an API was designed to use it, you are overriding the intent of 
the API maker and that won't give a good experience to the user.
Aug 26 2019
prev sibling parent reply JN <666total wp.pl> writes:
On Monday, 26 August 2019 at 22:19:38 UTC, aliak wrote:

 So if named arguments are accepted, from that release onwards 
 people will start writing:


Named arguments cover a specific usecase. The most common one is 
function calls with multiple optional arguments. After the DIP 
goes in, I don't see people using named arguments for everything.
Aug 27 2019
parent aliak <something something.com> writes:
On Tuesday, 27 August 2019 at 08:59:06 UTC, JN wrote:

 On Monday, 26 August 2019 at 22:19:38 UTC, aliak wrote:

 So if named arguments are accepted, from that release onwards 
 people will start writing:


 Named arguments cover a specific usecase. The most common one 
 is function calls with multiple optional arguments. After the 
 DIP goes in, I don't see people using named arguments for 
 everything.


You'd be surprised what people will use named arguments for.
Aug 27 2019