I’m interested in this feature and I’ve been thinking how to approach it.
First we should start with motivation - what problems do named arguments resolve?
For me, there are two primary reasons: readability and overloading.
Regarding readability, I find this code difficult to read:
connection.send("Hello world!", true), but this code is easy to read:
connection.send(message, wait_for_answer). Similarly, I find it easy to read this:
connection.send(message: "Hello world!", wait_for_answer: true).
What distinguishes those cases? It’s reasoning footprint as coined by Aaron Turon. In the unreadable case, it’s difficult to understand what that
true means without looking at the function definition. However, once there’s a name, it’s obvious what it does. So allowing naming of the parameters looks like a good idea.
The focus on reasoning footprint can guide us when designing how it should work. Clearly having to type
send(message: message) looks boilerpate-y, so it seems to me that it’s a good idea to allow omitting the name in case the variable name matches. This is extremely similar to how struct initialization works and in my opinion, it works very well.
I think that making it work just as structs would be also great because of being easy to remember that there are same rules.
Now, let’s look at overloading. What problems does it solve and what problems does it introduce? It removes the necessity of inventing a new name when two functions do same thing with different arguments. At the same time, it allows us to shoot us in the foot when combined with some other (mis)features like implicit conversions and makes type inference difficult. (I once spent ridiculous amount of time working with C++ because API of a library I used changed in a way that didn’t break my compilation but did break behavior. This situation would be prevented if C++ didn’t have implicit type conversion.)
It seems, that overloading isn’t a problem in Swift, because of explicit argument names. They resolve both issues: one wouldn’t be confused by what the code does thanks to the explicitness of names and at the same time, compiler doesn’t have to infer anything, because argument names are basically a part of the function name.
I wouldn’t propose that this should include overloading. It should be a separate proposal. But I’d propose to keep the door open, so we can add overloading later.