Another Look at Function Argument Labels in Swift

| | 4 Comments| 8:08 AM

Update: This post was written in 2014 when Swift first came on to the scene. As such it may be out of date and not applicable to Swift 2. Proceed with caution!

We’ve said it before and we’ll say it again: Make everything as simple as possible, but not simpler. Wait, no, Albert Einstein said that. We said more descriptive code is better code, and that’s one reason we fell in love with programming in Objective-C. This

is much less readable than

Yes, you have to type more, but the resulting code is easier to read and comprehend what is going on. Enough already with the trying to make code as compact or as short as possible!

The good folks at Apple must have also appreciated this feature of Objective-C enough to include it in Swift. Using named parameters you can declare functions that require argument labels in the function call. For example:

allows you to invoke the function as:

Failure to include the labels in the call will result in a missing argument labels error from the Swift compiler.

This is fine and all, but, it seems a bit annoying that when using an argument label that could be also be used as the variable name itself to have to provide some other name like s1 or s2. What would be nice is if we can require the argument label but then reuse that label as the variable name as well. Of course this post would come to an abrupt and unfulfilling end if there weren’t a way to do that. Fortunately there is!

Using the # symbol you tell Swift, “I want to use this as the argument label and the variable name.” Now rather than using s1 and s2 in your convertDegrees function, you can use fromScale and toScale.

The full source code:

Astute readers will notice that our enumeration could have used the String type, and we can improve on things further and take advantage of named elements in Swift tuples as well:

Throwing in named element tuples, we can refactor our entire function to:

A final look:

4 thoughts on “Another Look at Function Argument Labels in Swift”

  1. Thanks for the good explanation. I hope I learn to use that feature judiciously.

    One trouble with the blogging software you have is that the line width available to the code means we have to do lots of scrolling to see the whole lines. Is there a setting or a theme that would make the code sections expand indefinitely with the browser?


    1. Mark, thanks for the feedback. I’ve noticed the same thing and it’s beginning to annoy me. I’ll see what I can do to get a template that doesn’t require all that scrolling.

  2. I wanted to know if we could define the tuple and changed the function header to this:

    typealias Temperature = (degrees: Double, scale: TemperatureScale)

    func convertTemperature(temperature: Temperature, #toScale: TemperatureScale) -> Temperature

    That is a very satisfying thing to do.

    Also, this blog disabused me of a misconception: that if you didn’t assign a value to a var in the declaration, it would need to be an optional. With the move toward functional programming concepts, I thought that would be the thing to do.

    But we could have had that restriction in your example if the switch statement could be used like the ternary operator, and return a value. Not sure what the syntax would be, since he use of return would imply return from the function, but that would be a good step in the direction of functional programming.

Leave a Reply

Your email address will not be published. Required fields are marked *