4 ms·

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?

masklinn 11y ago
> The author completely missed the point of named parameters. 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) { … } which is called with a:c:, but the bindings are on b and d. You can also define this: func foo(a b: Int, _ d: Int) { … } which is called as `foo(a:5, 7)` which while somewhat consistent is really garbage.
- mikeash 11y ago
  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 11y ago
    > 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 11y ago
      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 11y ago
        > 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 11y ago
        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 11y ago
        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.

masklinn 11y ago

> The author completely missed the point of named parameters. 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) { … } which is called with a:c:, but the bindings are on b and d. You can also define this: func foo(a b: Int, _ d: Int) { … } which is called as `foo(a:5, 7)` which while somewhat consistent is really garbage.

mikeash 11y ago
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 11y ago
  > 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 11y ago
    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 11y ago
      > 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 11y ago
        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 11y ago
        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.