[mikeash]

In Swift terminology, a and c are "external names" while b and d are "local names." I don't see much of a difference between a "name" and a "label" here in any case.

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.

[masklinn]

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

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.

[mikeash]

Can you explain what "and require using when just wanting positional-only parameters, or consistently labelled parameters" means? I don't understand that.

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.

[masklinn]

> Can you explain what "and require using when just wanting positional-only parameters, or consistently labelled parameters" means? I don't understand that.

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.

[mikeash]

Yes, that's true, but note that you only need to specify the external names on the parameters that depart from the default. A function with external names on every parameter looks like:

    func whatever(a a: Int, b: Int, c: Int)

A function with no external names on any parameter looks like:

    func whatever(a: Int, _ b: Int, _ c: Int)

I'm not sure if you understood that or thought they all had to be specified if any were, but in any case that's how it looks.

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.

[wtetzner]

The question is why is the first argument special? Also, it's weird that you have to explicitly mark the label as "_" to get positional parameters.

I find Scala's handling of named arguments much saner.

[mikeash]

I think it's because the first argument tends to be named by the function itself. For example:

    button.setTitle("Ham and Cheese", color: red)

Note that named parameters are still positional, they just have names too. Using _ doesn't get you positional parameters, you already had that, it just removes the name. (Exception: named parameters with default values can be reordered with other adjacent named parameters with default values. Why? I don't know.)

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?

[Alphasite_]

For Swift, a lot of the designs were due to the ability to automatically transform Objective-C apis into swift APIs. The big issue from what i can tell is in extracting the first parameters name from the method name automatically.

[rimantas]

  > Then why have it in the first place? That seems like a very
  > odd feature to put front and center into the language

Cocoa is the answer.