Distinguishing parameter labels, names and values

Hi Richard,

All this terminology can be confusing right? Don't worry as Swift as many other upcoming iOS developers have trouble understanding the concept of parameter labels but it's actually quite simple. Let's break this down into three parts.

1. What a basic function looks like, how does it behave?

I'll use the calculateArea function as it's a good base for learning about these concepts.

func calculateArea(height: Int, width: Int) -> Int {
  return height * width
}

let area = calculateArea(100, 200) //-> 200

So as we've learned this is our typical run-of-the-mill function that contains two parameters, height and width; it also contains a return value which is required to be a signed integer value. Inside our function we have a simple return statement which multiplies the height by the width.

Pretty simple, yep.

2. What it looks like with parameter labels, now how does it behave?

So unlike our standard function above which doesn't require anything other than two integer values as arguments we need to declare labels with them if we do use them.

func calculateArea(myHeight h: Int, myWidth w: Int) -> Int {
  return h * w
}

let area = calculateArea(myHeight: 100, myWidth: 200) //-> 200

So... If you're confused because of the example Amit showed in the video don't fear as the label we define can be anything. When the Swift compiler sees our parameter labels it changes the function signature requiring them to be declared when passing in our arguments.

One other thing you will notice is instead of height and width as the parameter names they are now h and w, this is only an example but it shows how labels can take away some control from how we name our parameters allowing for much easier to read function signatures.

3. But wait, labels are only half the story

Another technique shown in the video are named parameters, unlike parameters these define an explicit function signature that can't be changed in anyway meaning you need to have parameters that are clearly named to prevent unexpected results when calling your function.

func calculateArea(#height: Int, #width: Int) -> Int {
  return height * width
}

let area = calculateArea(height: 100, width: 200) //-> 200

So what changed? Aside from adding a hash/pound symbol before height and width absolutely nothing. This example still behave the same way to how our parameter labels do with the exception that you can only change the parameter names to give more meaning to the arguments which 99% of the time can be accomplished using standard naming conventions.

What's next?

Try each technique, see which one fits best in your workflow.

Hope that helps.