DIP 1020--Named Parameters--Community Review Round 1

[rikki cattermole]

On 01/04/2019 11:22 AM, Bastiaan Veelo wrote:

> 1) Any DIP on named arguments nowadays should have references to all 
> prior suggestions and ideas, summarize them and categorize them and 
> clarify why this one is better.

That is a major rabbit hole. I will accept a write up from somebody 
else, but I do not feel like its a good idea to go down it.

> 3) What is the value of the following?
> 
>  > The function call `func(1, 2, o:true)` is the same as `func(1, 
> o:true, 2)` or `func(o:true, 1, 2)`.

As far as the assembly is concerned, yes.

> So is this equivalent at the definition site as well: `void func(int a, 
> int b, <bool o>);`, `void func(int a, <bool o>, int b);` and `void 
> func(<bool o>, int a, int b);`? Being able to reorder arguments somewhat 
> but not any way you like is confusing.

What matters is the relative ordering between the arguments. If the 
arguments are forced as per the declaration you lose the ability to 
express the call as the user sees fit. But if you go too loose you run 
into code smells and abuse.

This is a lose-lose situation. Some people hate full reordering, some 
hate no reordering. There is no way to win. With partial reordering 
perhaps we can have a compromise instead.

> 4) The section on overload resolution is flawed because it contains 
> illegal code:
> 
>  > `void bar(int a, string b = "", int c) {}`

Oof you are so correct.
It should be:

---
void foo(int a, <int c = 0>) {}
void foo(int a, string b = "", <int c = 0>) {}

void bar(int a) {}
void bar(int a, string b = "") {}
---

Does that make more sense now?
(I'll update the DIP with the fix after review)