DIP 88: Simple form of named parameters

[Chris Wright via Digitalmars-d]

On Sun, 24 Jan 2016 13:04:20 +0100, Jacob Carlborg wrote:
> On 2016-01-23 19:27, Chris Wright wrote:
>> I'd also add that this proposal doesn't affect UFCS.
> 
> How would it affect UFCS?

It shouldn't. However, it is another way to pass function arguments, so 
for thoroughness it would be better to mention it.

>> I'll note that parameter names are already part of documentation, and
>> they're already the only parameter documentation you're guaranteed to
>> have.
> 
> Currently it's possible to change a parameter name without the call site
> needing any change. Documentation has nothing to do with that.

I mentioned this because it strongly encourages people to use appropriate 
and descriptive names when writing functions. Appropriate and descriptive 
names are less likely to need to change. This doesn't eliminate your 
point that, today, people can change argument names and be guaranteed not 
to break client code.

>> Given this trend, people will be confused if they can't reorder named
>> parameters. The main benefit of not letting people reorder things is
>> reducing the amount of work *you* need to do when creating this DIP
>> (and the amount others need to do when implementing it).
> 
> No. The only reason why that is not allowed is to have a greater chance
> of the DIP being accepted. The language would be even more complicated
> if it was possible to reorder the arguments. It's a benefit for the
> users if the language is simpler.

There's more chance of it being rejected as not sufficiently beneficial 
and less chance of it being rejected as too much complexity. But let's 
look at that complexity angle. What sort of complexity do we want to 
eliminate?

There was recently a post that made the point that an hour of time from a 
compiler developer making something easier and saving each user an hour 
of time is a huge productivity gain in all. So we want to reduce 
complexity for language users, and making a more complex compiler is only 
problematic insofar as it makes the compiler slower or buggier.

All else being equal, adding constraints generally adds complexity and 
removing them generally reduces complexity. Any constraint we add has to 
pay for its complexity somehow. Having to remember parameter order while 
specifying unambiguously which parameter I'm trying to use is an added 
constraint and therefore added complexity. It gives nothing in return.

Since absolutely no language has previously required named arguments to 
retain the same order they're declared in, apparently everyone else 
disagrees that the feature is too complex. Even Python, which is 
specifically aimed at beginners, allows reordering.

The most similar thing to named parameters that's already in D is struct 
initializers. These do not require that you order the struct member 
initializers in the same order as the related fields are declared. This 
means that users have to remember two sets of similar syntax that 
function differently in an important way. That's added complexity within 
D.

It's a benefit to users if things work in a familiar way. I haven't been 
able to find a language that works in the way you propose, so for people 
familiar with other languages, this DIP results in confusing behavior. 
That's added complexity across languages. And since D doesn't have the 
same market penetration that Java or Javascript have, it's extremely 
difficult for a person to be familiar only with D.

>> Document how it's supposed to handle optional parameters
> 
> It's already documented.

I missed that. My apologies.

Your proposal says this works:

  void foo(int a: = 3, int b: = 4);
  foo();
  foo(a: 5, b: 6);

But we can conclude that the following is not allowed:

  foo(b: 6);

This is because it's not legal to change the order of arguments by 
specifying names, and you must supply optional parameters of the same 
type in order, without omitting any, if you don't have names. Your 
proposal did not involve any special casing here.

Is this what you intended? If so, please document it so other reviewers 
don't have to wonder.