DIP 88: Simple form of named parameters

[Jacob Carlborg via Digitalmars-d]

On 2016-01-23 19:27, Chris Wright wrote:

> One huge usecase for this is methods with many optional parameters.
> You've missed that. For instance, I wrote a method with six optional
> parameters recently. It's unusable without named parameters. I switched
> to a parameter struct, but it's still not that great.

I did not miss that. I deliberately chose to not support changing the 
order of the arguments.

> I'd also add that this proposal doesn't affect UFCS.

How would it affect UFCS?

> What about overloading based on parameter names? The proposal doesn't
> even mention the idea, so there's no guessing whether you considered and
> rejected it or just didn't consider it.

The DIP mentions that no change is required for function overloading. 
But I added an explicitly rule about that.

> 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.

> The Dart devs decided that named parameters must be explicitly set out as
> named, and they cited the same reason. The C# devs, on the other hand,
> made every parameter a named parameter. I haven't heard of any explosions
> in C# land, and it's been five years.
>
> Your proposal is closer to C#'s version than Dart's. In Dart, a named
> parameter cannot be called positionally:
>
>    foo({a, b}) {}
>    main() {
>      // This works:
>      foo(b: 1, a: 2);
>
>      // Error: 0 positional arguments expected, 2 found
>      foo(2, 1);
>    }
>
> In C#, a named parameter is only about the call site and has nothing to
> do with the function being called. A function you wrote for C# 1.1 and
> never modified can be called with named parameters in C# 4.0. You can
> still call these functions with positional-style parameters.
>
>> Changing the order when using the named parameter syntax is not legal:
>
> Why not?
>
> Let's look at languages with named parameters. Python: reorderable. C#:
> reorderable. Dart: reorderable. Scala: reorderable. Ada: reorderable.
>
> 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.

> Document how it's supposed to handle optional parameters

It's already documented.

-- 
/Jacob Carlborg