4 ms·
I love the internal/external labeling. With a little thought it can make for code that reads more nicely than is possible otherwise.
by 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 agoJavaScript has that with: const hello = ({ for: person }) => `Hello ${person}` hello({ for: "Dorian" }) 'Hello Dorian'
- yen223 3y agoJavascript'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 agoIt does indeed, but the cost is an object allocation for every function call.
- airstrike 3y agoit's one of those small things that are also brilliant in hindsight
- MBCook 3y agoObjective-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 agocrystal has it too, and i agree, it's a very nice feature
- stevepotter 3y agoNamed 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)