The author completely missed the point of named parameters. How am I supposed to know that the string argument of "make_window" is the title?
The author didn't miss the point of named parameters. At no point does the author even cover the point of named parameters. The author complains that:
1. they're inconsistent, all parameters but the first are named by default and named parameters are still positional (you can't reorder "named" parameters in the callsite)
2. making parameters purely positional is non-obvious and ugly
And he missed the part which takes the cake: Swift doesn't actually have named parameter, parameters 1+ are labelled (#1), and labels and names are independent, you can define this:
func foo(a b: Int, c d: Int) { … }
func foo(a b: Int, _ d: Int) { … }
I don't understand why the ability to set different external and local names is so bad. External names are part of the API, local names are part of the implementation. It often makes sense to make them the same, but there are case where you want them to be different, and what's wrong with that? It's ultimately no different from loading a parameter into a local variable of a different name and then operating on that local variable. Yes, you can use this facility to make ugly APIs, but you don't have to.
Then why have it in the first place? That seems like a very odd feature to put front and center into the language (considering a very similar effect can be achieved with a few assignments as the function's prelude) and require using when just wanting positional-only parameters, or consistently labelled parameters.
As for why you have it in the first place, it's just because one is API and one is implementation, and there are sometimes good reasons to have them be different.
As far as I can see (and the article notes), by default the first parameter of a Swift function is unlabelled, and the others are labelled. That is at callsite the first parameter can not be labelled and the others must be. Having either all-positional or all-labelled (but still positional) requires specifying external names.
> As for why you have it in the first place, it's just because one is API and one is implementation
But again and as you yourself noted that could trivially be done with local bindings inside the function in cases where it's desirable.
func whatever(a a: Int, b: Int, c: Int)
func whatever(a: Int, _ b: Int, _ c: Int)
As for "that could trivially be done," that applies to a lot of language features in a lot of languages. Virtually all language features are redundant in that fashion, yet they can still be useful by adding brevity and clarity.
I find Scala's handling of named arguments much saner.
button.setTitle("Ham and Cheese", color: red)
It is mildly annoying that you have to add an extra symbol to remove the name for parameters after the first one, but that's the language pushing its preferred style.
How does Scala handle all this?
That's actually nice to know.
> How does Scala handle all this?
No idea about Scala. In Python 3, there are 4 "classes" of parameters:
* "positional-and-named", the basic parameter can be passed either by name or by position, though passing parameter 1 by name parameter 2 by position won't work: when actually calling the function, the interpreter first fills positional parameters left-to-right then applies named parameters, so it'll raise an error noting that one parameter got two values[0]. Can be either required or with a default value. Parameters passed by names can be passed in any order
def foo(a, b, c=5): pass
foo(1, c=42, b=3)
def foo(*args): pass
foo(1, 2, 3, 4)
def foo(*, a, b, c=5): pass
foo(b=6, a=2)
def foo(**kwargs): pass
foo(bar=5, baz=42, qux=1)
[0] the reverse won't work either, at callsite Python doesn't allow named parameters to be provided before positional ones
> Then why have it in the first place? That seems like a very
> odd feature to put front and center into the language