### Trailing Closures

The Swift programming language also defines a concept known as trailing closures. If you pass a closure as the last argument of a function, you can place that closure outside the parentheses of the function call. The following example demonstrates how this works.

If the only argument of the function call is the closure, then it's even possible to omit the parentheses of the function call.

Note that this also works for closures that contain multiple statements. In fact, that is the main reason trailing closures are available in Swift. If a closure is long or complex and it's the last argument of a function, it is often better to use the trailing closure syntax.

## 3. Protocols

Protocols are an important component of the Swift programming language. The concept isn't difficult to understand if you're familiar with protocols in Objective-C or interfaces in Java. A protocol defines a design or interface focused on a particular task. It does this by defining properties and methods necessary to perform that task.

Defining a protocol looks similar to defining a class or structure. In the following example, we define the Repairable protocol. The protocol defines two properties, time and cost, and a method repair(). The time property is readonly while the cost property is readwrite.

A class or structure can adopt a protocol by conforming to it. This means that it is required to implement the properties and methods defined by the protocol. Let's update the Boat class we implemented in the previous tutorial.

That's how easy it is to conform a type to a protocol. Even though a protocol cannot be instantiated like a class or structure, a protocol is a valid type. Take a look at the following example in which the Repairable protocol is used as the type of a function argument.

Davis Allie recently wrote a great article about protocol-oriented programming in Swift. If you're interested in learning more about protocols and their potential in Swift, then I encourage you to read Davis' article.

## 4. Access Control

I'd like to conclude this introduction to Swift by talking about access control. As the name implies, access control defines which code has access to which code. Access control levels apply to methods, functions, types, etc. Apple simply refers to entities. There are three access control levels, public, internal, and private.

• Public: Entities marked as public are accessible by entities defined in the same module as well as other modules, such as a project, framework, or library. This access control level is ideal for exposing the interface of a framework.
• Internal: This is the default access control level. In other words, if no access control level is specified, the internal access control level applies. An entity with an access level of internal is only accessible by entities defined in the same module.
• Private: An entity declared as private is only accessible by entities defined in the same source file.

Take a look at the following example in which I've updated the Boat class. The class itself is marked as public, which means it's accessible from anywhere. The cost property is implicitly marked as internal, because we haven't specified an access control level. The same is true for the deployLifeboats() method.

The scheduleMaintenance() method is marked as private, which means that it can only be invoked by entities defined in the source file in which the Boat class is defined. It's important to understand this, because it's slightly different from what other programming languages consider a private method or property.

If we mark the Boat class as internal by removing the public keyword, the compiler will show us a warning. It tells us that we cannot mark speed and lifeboats as public as long as Boat is marked as internal. The compiler is right of course. It doesn't make sense to mark the properties of an internal class as public.

## Conclusion

The Swift programming language is easy to pick up, but there's so much more to it than what we've covered in the past two tutorials. You'll learn more about Swift once we start building applications. In the next article, we take a closer look at  the iOS SDK.

If you have any questions or comments, you can leave them in the comments below or reach out to me on Twitter.