5 ms·

Not having keys in function parameters is a mistake. Swift does have an unconventional approach to function keys though, wherein you can specify an "external"

by yen223 3y ago

Not having keys in function parameters is a mistake. Swift does have an unconventional approach to function keys though, wherein you can specify an "external" label and an "internal" label: func greeting(for person: String) -> String { "Hello, " + person + "!" // the argument is "person" inside the function body... } print(greeting(for: "Dave")) // ... but it's "for" when calling the function I'm not sure if I like it or hate it, but it is cool.

jwells89 3y ago
I love the internal/external labeling. With a little thought it can make for code that reads more nicely than is possible otherwise.
- dorianmariefr 3y ago
  JavaScript has that with: const hello = ({ for: person }) => `Hello ${person}` hello({ for: "Dorian" }) 'Hello Dorian'
  - yen223 3y ago
    Javascript's one is a little bit different in that you are renaming the destructured variable - it's not a function-specific thing - whereas Swift's version is a property of the function. e.g. const user = {id: "123"}; const { id } = user; // This extracts the `id` field const { id: userId } = user; // This also extracts the `id` field, but renames it to userId console.log(userId)
  - jahewson 3y ago
    It does indeed, but the cost is an object allocation for every function call.
- airstrike 3y ago
  it's one of those small things that are also brilliant in hindsight
  - MBCook 3y ago
    Objective-C sort of had it unofficially through how methods tended to be named. I’m glad they found a nice way to do it in Swift.
- zem 3y ago
  crystal has it too, and i agree, it's a very nice feature
- stevepotter 3y ago
  Named parameters and nothing new and I like them. To this day I don’t understand why swift/objc have two names. I get that one is external, one internal so changing external breaks APIs. So is the only advantage that you can rename the parameter name for function implementation? So what? You can do that by a variable at the top of the function. Those two names make function signatures hard to read (which one is which etc)
travisgriggs 3y ago
It’s one of the things I miss most in Kotlin.
cherryteastain 3y ago
Even C/C++ have the internal/external mismatch: // in greeting.h void greeting(char* for); // in greeting.c void greeting(char* person) { ... }
tcmart14 3y ago
For me, I felt the same way initially, but I found it depends on the case. The case you gave is probably now one I would do, I would probably have the external be 'for' if I expected the caller to pass in a list that I was gonna iterate over inside of the method. An example I like to use to show when and how I used it. I have been playing with Metal. If I write a function called translate, I will have it's external parameter as 'by' with the internal parameter being 'vector'. As a simple example: func translate(_ origin: simd_float3, by vector: simd_float3) -> simd_float3 { // do some stuff } let newVector = translate(originalVector, by: translatingVector)

by yen223 3y ago

jwells89 3y ago

I love the internal/external labeling. With a little thought it can make for code that reads more nicely than is possible otherwise.

dorianmariefr 3y ago
JavaScript has that with: const hello = ({ for: person }) => `Hello ${person}` hello({ for: "Dorian" }) 'Hello Dorian'
- yen223 3y ago
  Javascript's one is a little bit different in that you are renaming the destructured variable - it's not a function-specific thing - whereas Swift's version is a property of the function. e.g. const user = {id: "123"}; const { id } = user; // This extracts the `id` field const { id: userId } = user; // This also extracts the `id` field, but renames it to userId console.log(userId)
- jahewson 3y ago
  It does indeed, but the cost is an object allocation for every function call.
airstrike 3y ago
it's one of those small things that are also brilliant in hindsight
- MBCook 3y ago
  Objective-C sort of had it unofficially through how methods tended to be named. I’m glad they found a nice way to do it in Swift.
zem 3y ago
crystal has it too, and i agree, it's a very nice feature
stevepotter 3y ago
Named parameters and nothing new and I like them. To this day I don’t understand why swift/objc have two names. I get that one is external, one internal so changing external breaks APIs. So is the only advantage that you can rename the parameter name for function implementation? So what? You can do that by a variable at the top of the function. Those two names make function signatures hard to read (which one is which etc)

travisgriggs 3y ago

It’s one of the things I miss most in Kotlin.

cherryteastain 3y ago

Even C/C++ have the internal/external mismatch: // in greeting.h void greeting(char* for); // in greeting.c void greeting(char* person) { ... }

tcmart14 3y ago

For me, I felt the same way initially, but I found it depends on the case. The case you gave is probably now one I would do, I would probably have the external be 'for' if I expected the caller to pass in a list that I was gonna iterate over inside of the method. An example I like to use to show when and how I used it. I have been playing with Metal. If I write a function called translate, I will have it's external parameter as 'by' with the internal parameter being 'vector'. As a simple example: func translate(_ origin: simd_float3, by vector: simd_float3) -> simd_float3 { // do some stuff } let newVector = translate(originalVector, by: translatingVector)