NEW: My new book Pro SwiftUI is out now – level up your SwiftUI skills today! >>

Where did we learn about this?

Forums > SwiftUI

Started day 13 today and right away I don't recognize what I'm looking at.

func commute(distance: Int, using vehicle: Car) {
    // lots of code here

Specifically this part:

using vehicle: Car

First, I. have to mention how difficult it is to search on a term like "using" even in the context of swiftui. Ha. Maybe therel's an official documentation site somewhere, like PHP has?

I then looked into the past lessons. The closest thing I found was Day 9 and passing functions into functions. But, the format there is:

func makeArray(size: Int, using generator: () -> Int) -> [Int] {

Is he passing the Cars struct to the function without a parenthesis? I would expect to see

using vehicle: (Car)

based on what I've learned so far. But, the shorthand stuff and lack of things like semicolons is kind of melting my brain.

So, when passing a struct to a function, no parentheses?

Edit: Facepalm! I just remembered that structs are a way to create Types, right? So referring to our own struct names is just like referring to Int or String. But, still please let me know if I got that right.


So your are just saying your function will have a parameter that will have to be of type Car , which in your case is a struct, so yes Car is like Int or String , but in this case its your custom type , so yes your are right , the 2 names for parameter are just for our use again ... one to be used internally inside function(vehicle), the first one will be used when calling it using....

when we call function some where we need it , it will use using , you can use any meaningful name if you want

makeArray(size: , using : )


Mark wonders about function signatures:

Started day 13 today and right away I don't recognize what I'm looking at.

You are looking at the signature of a function. Reading signatures is a skill that you must learn, and yes! it will melt your brain for a bit. When you look at a function's signature, read it OUT LOUD until it makes sense to you.

In your code below, using vehicle is not a Swift command. So you will NOT find this with google searching. using and vehicle are function parameters. These are two variables that you use both outside (using) and inside (vehicle) your function.

func commute(distance: Int, using vehicle: Car) {
    // lots of code here

See -> Learn to read Function Signatures

@twoStraws has a great video that you should also review.

See -> Customize Parameter Labels


Firstly learned in the Day 7 : Why does Swift use parameter labels?.

You can make the "call" read how you want by using internal and external parameters.

1st with only one parameters

func commute(vehicle: String) {
    print("I'm traveling by \(vehicle)")

commute(vehicle: "Car")

2nd with two parameters

func commute(using vehicle: String) {
    print("I'm traveling by \(vehicle)")

commute(using: "Car")

And the last one with external parameter by using a _

func commute(_ vehicle: String) {
    print("I'm traveling by \(vehicle)")


Now you choose how each call is made and which reads better (mine is with two on this example). However something like might read better.

func square(_ number: Int) -> Int {
    number * number



Isn't "using" used as a reserved word for passing a function to a function?

func makeArray(size: Int, using generator: () -> Int) -> [Int] {

-from Day 9

So, I don't think it's day 7 stuff. It seems like it was just confusing to see the Cars type passed like that. I wasn't really thinking about it being passed to a function, just wondering why it didn't need parenthsis if it's a parameter.

It seems that the syntax for swift is just weird for me. Thanks though


It is the same as this example.

The first name given to a function's parameter is for use outside of the function definition. (when you call the function)

The second name given to a function's parameter is for use inside of the function definition. (when you are writing what a function does)

func divide(_ number: Double, by divisor: Double) -> Double {
    number / divisor

In this case, the first parameter only has one name (the second name), as we have used the underscore as the first name. This way, you don't have to use a name at all when calling the function. But we used the name "number" to refer to it inside of the function definition.

But the second parameter has two names given, so you would use the first one "by" when you call the function, but we used the second name "divisor" to refer to it inside the function definition.

This allows us to call the function like this

divide(12, by: 4)

The purpose is that you can read it much more naturally this way, and know what it does much easier than...

divide(number: 12, denominator: 4)


If you are confused about Car being passed as a parameter, you need to understand that any struct or class that you create is just like any other type of data at that point. So, if you have a Car struct, it is just as much a data type as Int or String. You can pass an instance of it to a function, store it in an array, or do whatever else you may need to do with it.

You only need to use Parenthesis after a type name when you are creating a new instance of that type by calling an initializer for the struct/class.

You can create a new Int from a String when you use


You can create a new String from an Int when you use


You can create a new Car when you use


(With any parameters that the initializer requires between the parenthesis)

But after you have created an instance of the type that you are creating, you can pass it to a function by simply using the name of the variable that you stored it in. No parenthesis needed.

When you are defining a function, and list Car as the type of one of the parameters you don't need to use parenthesis there either. You arent creating a new instance of Car, you are just saying that the parameter's type is Car just as you would do with an Int or String.


@mark_ -r - This is not some logical stuff, its the way the compiler understands stuff, every thing we write is to satisfy the conditions laid out in the compiler , many of us cannot understand every thing, so just try and move on, its a really small thing ... which will sort itself out in coming days, the frustations you feel, we all go through ... good luck


Hacking with Swift is sponsored by Play

SPONSORED Play is the first native iOS design tool created for designers and engineers. You can install Play for iOS and iPad today and sign up to check out the Beta of our macOS app with SwiftUI code export. We're also hiring engineers!

Click to learn more about Play!

Sponsor Hacking with Swift and reach the world's largest Swift community!

Reply to this topic…

You need to create an account or log in to reply.

All interactions here are governed by our code of conduct.

Unknown user

You are not logged in

Log in or create account

Link copied to your pasteboard.