Learn iOS 8 App Development, Second Edition (2014)

Directive	Meaning
public	Any code can use this property or function.
internal	Only the code in the app or framework where this class is defined can access this property or function.
private	Only functions in this class may access this property or function.

When I say “access,” I mean refer to that property, or call that function, in any statement. The internal keyword is only interesting when developing frameworks. It’s a middle ground between private and public. For code in the same app or framework, it acts like public access. For code outside the app or framework, it acts like private access.

Note If you omit the access control, it defaults to internal. Almost all of the time this means that your properties and functions will be public. If you start using your classes in frameworks, you’ll need to explicitly declare your public interfaces using the public keyword.

Playgrounds

But don’t take my word for it. Create a new playground and try any of the code snippets in this chapter, or anything else you want to try in Swift. A playground is an interactive Swift document that simultaneously compiles and runs whatever code you put there.

From the Xcode File menu, choose the New Playground command, or just create a new file and choose the Playground template. Give the playground a file name and save it somewhere. You now have a blank slate to try Swift features, as shown in Figure 20-1.

Figure 20-1. Swift playground

You type in code on the left, and the results appear on the right. The right-hand pane will show you what values were set, what an expression evaluates to, how many time a loop ran, the last value returned from a function, and so on. Change your code, and everything is evaluated again.

There are playground files for most of the sections in this chapter. They contain the code snippets described here, along with additional examples and comments. The playgrounds for this chapter can be found in the Learn iOS Development Projects Ch 20 folder, and all have fairly obvious names. The playground for this section is Classes.playground.

Properties

A property is a value that belongs to an instance of that class—that is, an object. There are two kinds of properties: stored and computed. A stored property allocates variable space within the object to retain a value. You declare a stored property as follows:

class ClassStoringProperties {
let constantProperty: String = "never changes"
var variableProperty: Int = 1
}

A let defines a constant (immutable) property. A var defines a variable (mutable) property. You can obtain the value of either, but you can only change (mutate) the value of a var.

A property has a name, a type, and an optional default value. You can omit the type or the value. If you omit the type, the type is inferred from the value you’re setting it to, as follows:

let constantProperty = "never changes"
var variableProperty = 1

These two properties are identical to the previous two. Their types (String and Int) were inferred from the types of their default values. If you don’t specify the type of a property, its type will be the type of the value you set it to.

In Swift, all variables must be initialized when they are declared. It is strictly forbidden to declare a variable or constant that is not set with an initial value. This eliminates a whole class of common programming mistakes that arise from uninitialized variables.

Within a class (or structure) you can bend this rule a little. You can declare a stored property that doesn’t have a default value, as long as you provide its initial value when the object is initialized. In a class, it’s legal to write the following:

var uninitializedProperty: Int

If you do this, you must provide an initializer function that sets uninitializedProperty to a value before the object can be used. I cover initializer requirements a little later in this section.

Computed Properties

Computed properties, sometimes called synthetic properties, are property values that are calculated by a block of code. They have no variable storage associated with them, but they often use other stored properties in their calculations. The following is an example of a computed property:

class ClassCalculatingProperties {
var height: Double = 0.0
var width: Double = 0.0
var area: Double {
get {
return height*width
}
set(newArea) {
width = sqrt(newArea)
height = width
}
}
}

This class has two stored properties and one computed property. The computed area property can be used just like any other property, as follows, but its value when retrieved is determined by the code in the get block of the property. This is called the property’s getter. The getter is required.

let calculatingObject = ClassCalculatingProperties()
calculatingObject.height = 9.0
calculatingObject.width = 5.0
let area = calculatingObject.area /* area = 45.0 */

If you want the property to be mutable, you can also supply a setter function, as shown. The parameter to the set(newArea) code block contains the value to be set. If you omit the setter, the property is read-only. It also means you can use a shorthand syntax that drops the get { ... }portion, as follows:

var area: Double { return height*width }

Even if the value returned by a read-only computed property never changes, you must still declare the property using the var keyword. The logic is that the value could change—there’s no way for Swift to know otherwise—so it must be declared to be a variable.

Property Observers

You can also attach code to a stored property. When a stored property is set, you have two opportunities to execute code: a willSet and a didSet code block. You declare these immediately after the stored property, much like a computed property, as follows:

class ObservantView: UIView {
var text: String = "" {
didSet(oldText) {
if text != oldText {
setNeedsDisplay()
}
}
}
}

In this example, the code in the didSet(oldText) block executes whenever the text property is assigned. The didSet code block executes after the property has been updated; the parameter contains the previous value. Here, it’s used to determine whether the string actually changed and redraws the view only if it did.

Similarly, the willSet code block executes before the stored property is updated. Its single parameter is the new value to be set. If you want to override the value being set, change the property’s value in the didSet function to something other than what was set.

Tip When writing set, willSet, and didSet code blocks, you can either choose a name for the single parameter or leave it out. If you leave it out, Swift supplies a parameter named newValue, newValue, or oldValue (respectively) for use in your code.

You can’t attach code that executes when a stored property is read. And you can’t attach property observers to a computed property. The latter would be redundant since the setter code can do anything a property observer could.

Methods

A function in a class is called a method, an instance method, an instance function, or sometimes a member function. It’s a function that runs in the context of an object. You declare methods as a function in the body of the class, as follows:

func pokeUser(name: String, message: String) -> Bool {
return true
}

This method is passed two parameters and returns a Boolean value. You would invoke it with a statement such as the following:

let result = object.pokeUser("james", message: "Is that an ice cream truck I hear?")

If the function does not return a value, omit the return type that follows the parameter list (-> ReturnType).

Class Methods

A class method is like a global function, but it belongs to the class. A class method does not execute in the context of an object. You declare a class method using the class keyword, as follows:

class GoldenAge {
class func timeRemaining() -> Double { ...

You call a class method using the class name (instead of an object reference), as follows:

let remaining = GoldenAge.timeRemaining()

Because a class method does not execute in the context of an object, you can’t refer to any property or instance function of the class directly. This even applies to constants.

Class methods are often used to provide access to global resources, as getters for singletons, or as factory methods to create configured objects.

Parameter names

Every parameter in a function has two names: an external parameter name and a local parameter name. The following function has three parameters with six names:

func poke(user name: String, say message: String, important priority: Bool) -> Bool {
if priority {
sendMessage(message, toPerson: name)
return true
}
return false
}

In this example, every parameter has both an external and a local parameter name, and they are all different. In the function’s code, you use the local parameter names (name, message, and priority) to refer to their values.

When calling the function, you use the external parameter names (user, say, important). The following statement will call that function:

poke(user: "james", say: "Wouldn't some ice cream be great?", important: true)

Optional Parameter Names

Both local and external parameter names are optional. If there is no external parameter name, the call’s argument list includes only the value. The following function and function call demonstrate this:

func pokeUser(name: String, message: String) { ... }

pokeUser("james", "I swore I heard the ice cream truck!")

If you omit the external parameter name, Swift may use the local parameter name as the external parameter name. For example, the following two method declarations are identical:

class ExternalNamesInAClass {
func pokeUser(name: String, message: String) { ... }
func pokeUser(name: String, message message: String) { ... }
}

In both functions, the initial parameter has no external name, while the last one does. In the first function, Swift used the local name of the last parameter as its external name. Both of these functions would have to be called as follows:

pokeUser("james", message: "I'm going to get ice cream.")

So, why does this happen? Swift’s expectations about external parameter names vary based on the context of the function as follows:

· A function declared outside a class, structure, or enumeration (sometimes called a global function) is not expected to have any external parameter names. If you declare an external name, it will be required to call the function. If you omit it, that argument will be bare.

· A method (a function declared in a class) does not expect an external name for the first parameter but does expect one for all remaining parameters. If you omit an external name, the local name will be used as the external name starting with the second parameter.

· If your parameter provides a default value (see the section “Default Parameter Values”), Swift expects it to have an external name.

· A class or structure initialization function (init()) is expected to have external names for all parameters. If you omit any, the local name is used as the external name.

The first rule makes Swift functions consistent with C, Java, and similar languages. If you don’t declare external parameter names, your function calls will look like those legacy languages. You have the option of using Swift’s more expressive named parameters, but it’s not a requirement.

The second rule is intended to make adopting Objective-C’s method naming convention easy within classes. Objective-C doesn’t make a distinction between function and parameter names. An Objective-C method name is really just a sequence of tokens that separate the parameters. Consequently, the first token of an Objective-C method typically names the first parameter as well, as in the setBool(_:,forKey:) method (or -setBool:(bool)b forKey:(NSString)key, as it’s written in Objective-C). The first parameter is the Boolean value, already identified in the function’s name. You wouldn’t want to write setBool(bool: true, forKey: "key").

The final rule is to make it easy to create multiple initializers without getting them mixed up. All functions must have a unique signature. Since the function name of all initializers is init, Swift must have unique external parameter names to distinguish between them.

Parameter Name Shortcuts

If you want to specify an external parameter (where Swift does not enforce one) and your external and local parameter names are the same, you can use one name for both by using a # (pound sign or hash) for the external name. The following two function declarations are identical:

func function(parameter parameter: Int)
func function(# parameter: Int)

Conversely, you can force Swift to not use an external parameter name—in those circumstances where it normally would—by replacing the external name with an _ (underscore) character. You can suppress the external parameter name in the poke(_:,message:) function by writing it as follows:

func poke(name: String, _ message: String)

Now you would call this function simply as object.poke("james","What flavor?").

You can also ignore the local parameter name. Do this when you have no interest in that parameter. For example, the UIControl classes send actions by calling a method whose single parameter is the control object that caused the action. A typical action method looks like this:

@IBAction func sendPoke(sender: AnyObject)

Quite often, the action method has no use for the sender parameter. You can signal your disinterest by replacing the local parameter name with an _ (underscore) character, as follows:

@IBAction func sendPoke(_: AnyObject)

The parameter is still there, and the caller is still required to supply it, but the function’s code ignores it.

Default Parameter Values

You can supply a default value for one or more parameters. If you do, you can optionally omit that parameter from the function call and the function will receive the default value. You assign default values in a function’s declaration, as follows:

func pokeUser(name: String, message: String = "Poke!", important: Bool = false )

The second and third parameters have default values. Either or both can be omitted from a function call. If you omit the argument in a call, the parameter will be set to the default value. All four of the following statements call this function:

defaulter.pokeUser("james")
defaulter.pokeUser("james", message: "Where's my ice cream?")
defaulter.pokeUser("james", important: true)
defaulter.pokeUser("james", message: "The ice cream is melting!", important: true)

For clarity, parameters with default values should have external names. Swift assumes this and will use the local name as the external name if you omit it. To avoid ambiguity, any subsequent parameters should also have external names.

Inheritance

A class can inherit from another class. When it does so, it acquires all of the properties and methods of its superclass. The class then augments this foundation with additional properties and methods.

A class can override a method of its superclass. When you do this, you must prefix the method with the override keyword, as follows. This prevents you from accidentally overriding a method because you happened to pick a function name that was already implemented.

class BaseClass {
var lastUserPoked: String = "james"
func pokeUser(name: String) {
sendMessage("Poke!", toUser: name)
lastUserPoked = name
}
}

class SubClass: BaseClass {
override func pokeUser(name: String) {
println("someone poked \(name)")
}
}

A method has a special super variable that refers to the methods and properties of its superclass. Use the super variable to invoke the superclass’ method, instead of the one overridden by your class, as follows:

class SubClass: BaseClass {
override func pokeUser(name: String) {
super.pokeUser(name)
println("someone poked \(name)")
}
}

Overriding Properties

You can also override any property with a computed property. The property you’re overriding may be a stored property or another computed property. Again, you use the override keyword to signal your intent. In the following example, the subclass is creating a computed propertylastUserPoked that overrides the stored property (lastUserPoked) defined in the base class.

class SubClass: BaseClass {
override var lastUserPoked: String {
get {
return super.lastUserPoked
}
set {
if newValue != lastUserPoked {
println("caller is poking a different user")
}
super.lastUserPoked = newValue
}
}
}

Notice how the computed property uses the super.lastUserPoked syntax to access the stored property defined in the base class.

Alternatively, you can override a property observer, as follows:

override var lastUserPoked: String {
didSet {
...
}
}

The inherited property can be either a stored or computed property, but it must be mutable; property observers are only executed when the value is set.

Blocking Inheritance

If you want to cut out any heirs to your class, methods, or properties, use the final keyword. The following class defines a property and method that are final:

class ClassWithLimitedInheritance {
final var trustFundName: String = "Scrooge McDuck"
final func giveToCharity(amount: Double) {
if amount > 2.00 {
println("Too much!")
}
}
}

You can create a subclass of ClassWithLimitedInheritance and extend it, but you cannot override its trustFundName property or its giveToCharity(_:) method. If you want to prohibit all subclassing, add the final keyword to the class itself, as follows:

final class EndOfTheLine: ClassWithLimitedInheritance { ...

Object Creation

You create a Swift object by writing the class’s name as if it were a function call. The following statement creates a new ClassCalculatingProperties object and assigns it to calculatingObject:

let calculatingObject = ClassCalculatingProperties()

This syntax allocates a new object and invokes one of the class’s initializer functions. In this example, that was init()—the initializer with no parameters. You can write your own class initializers. You write one just like a member function with the exceptions that you omit the funckeyboard, the name of the function is always init, and it does not return a value, as follows:

class SimpleInitializerClass {
var name: String
init() {
name = "james"
}
}

Every class must have at least one initializer function, else how are you going to create objects? In the following class, all stored properties have default values, and the class doesn’t declare any initializers of its own. In this situation, Swift creates an init() initializer for you.

class AutomaticInitializerClass {
var name = "james"
var superUser = true
// init() supplied by Swift
}

You can define as many initializers as you want. They can also include default parameter values, as shown here:

class IceCream {
var flavor: String
var scoops: Int = 1
init() {
flavor = "Vanilla"
}
init(flavor: String, scoops: Int = 2) {
self.flavor = flavor
self.scoops = scoops
}
}

Tip If a local variable name has the same name as a property, use the self variable to distinguish between them. flavor refers to the local parameter. self.flavor refers to the object’s flavor property.

Your initializers are distinguished by their external parameter names (since they all have the same function name). Swift chooses the initializer based on the parameter names, as follows:

let plain = IceCream()
let yummy = IceCream(flavor: "Chocolate")
let monster = IceCream(flavor: "Rocky Road", scoops: 3)

Note All swift values are created using the same syntax. The expression CGFloat(1.0) creates a new CGFloat value equivalent to the Double constant 1.0. The expression Weekday(rawValue: 1) creates an enumeration value equal to .Monday, and so on.

Subclass Initializers

If your class is a subclass, your initializer must explicitly call one of the superclass’ initializers. In the following subclass, the initializer sets up its properties and then invokes the superclass’ initializer so the superclass can initialize its properties:

class IceCreamSundae: IceCream {
var topping: String
var nuts: Bool = true
init(flavor: String, topping: String = "Caramel syrup") {
self.topping = topping
super.init(flavor: flavor, scoops: 3)
}
}
}

Safe Initialization

Swift consistently enforces the rule that you cannot use any value, class, or structure until every variable has been initialized. Swift also lets you defer the initialization of stored properties to your initializer function. This can lead to a bit of a chicken-and-egg problem.

Let me demonstrate the problem by adding an addCherry() function to the IceCream class and then override it in the IceCreamSundae class, as follows:

class IceCream {
...
init(flavor: String, scoops: Int = 2) {
self.flavor = flavor
self.scoops = scoops
addCherry()
}
func addCherry() {
}
}

class IceCreamSundae: IceCream {
...
init(flavor: String, topping: String = "Caramel syrup") {
super.init(flavor: flavor, scoops: 3) // <-- invalid initializer
}
override func addCherry() {
if topping == "Whipped Cream" {
...
}
}
}

Consider how an IceCreamSundae object gets created. When the initializer for IceCreamSundae starts to execute, the topping property is not yet initialized because it has no default value. You can’t call the superclass initializer (super.init(flavor:,scoops:)) yet because there’s a possibility that it might call the addCherry() function (which you overrode), which could then access the uninitialized toppings property.

To solve this dilemma, Swift requires all initializers to perform their work in three phases, in the following order:

1. Initialize all stored constants and variables, either explicitly or by relying on the property’s default value.

2. Call the superclass initializer to initialize the superclass.

3. Perform any additional setup that would involve calling methods or using computed properties.

The first thing the IceCreamSundae initializer must do is to ensure that all of its properties are initialized. The correct way to write the IceCreamSundae initializer is as follows:

class IceCreamSundae: IceCream {
...
init(flavor: String, topping: String = "Caramel syrup") {
self.topping = topping
super.init(flavor: flavor, scoops: 3)
}

The single self.topping = topping statement satisfies the requirement of the first phase. The topping property does not have a default value and must be explicitly set. The nuts property has a default value; if you don’t set it to something else, Swift will set it to true for you. At this point, all subclass properties have been initialized.

Note Property observers are never executed during object initialization.

This is also the one place in Swift where you can set immutable constants. Even if a property is declared as a constant (let preferDarkChocolate = true), you can set it during the first phase of object initialization.

The second phase must call the superclass initializer. This will initialize all of its properties, its superclass’s properties, and so on.

When the superclass initializer returns, the object is fully initialized. It is now safe to call any member function or use any property to prepare the object for use.

Your initializer might be missing some of these phases.

· If the class has no stored properties or all stored properties have default values, the first phase isn’t needed.

· If the class doesn’t have a superclass, there’s no superclass initializer to call, and no second phase.

· If the class doesn’t have any initialization beyond Swift’s requirements, there won’t be a third phase.

Convenience Initializers

The initializers I’ve described so far are called designated initializers. A designated initializer is an initializer that implements the three phases outlined in the previous section.

You can also create convenience initializers. A convenience initializer makes it easier to create objects by providing a simplified interface but defers the important work of initializing the object to another initializer in the same class. You declare a convenience initializer with theconvenience keyword. The following code adds a convenience initializer to the IceCreamSundae class:

convenience init(special dayOfWeek: Weekday) {
switch dayOfWeek {
case .Sunday:
self.init(flavor: "Strawberry", topping: "Whipped Cream")
case .Friday:
self.init(flavor: "Chocolate", topping: "Chocolate syrup")
default:
self.init(flavor: "Vanilla")
}
}

You can now create the ice cream sundae du jour with the following statement:

let sundaySundae = IceCreamSundae(special: .Sunday)

Note the use of self.init(...) to call another initializer in the same class. The called initializer must be in the same class and be either a designated initializer or another convenience initializer that eventually calls a designated initializer.

Inheriting Initializers

Initializer inheritance gets a little tricky. For the complete story, refer to The Swift Programming Guide in iBooks, but here are the basic rules:

· If your subclass doesn’t define any initializers of its own and all of its stored properties have default values, the subclass inherits all of the initializers from its superclass. (Technically, Swift generates all of the designated initializers for you.)

· If your subclass overrides an initializer, you must prefix it with an override keyword, just like a method or property.

· If your subclass declares any uninitialized stored property variables or constants, you are required to implement designated initializers to set those values.

· If your subclass implements any of its own initializers, it won’t automatically inherit any designated initializers. If you want the same designated initializers in your subclass, you must override and re-implement them all.

· You only inherit convenience initializers that call a designated initializer that your subclass also provides (either through inheritance or by overriding it).

As an example, the following BananaSplit class subclasses IceCreamSundae. It doesn’t declare any stored properties without default values. If that was all it did, it would have been eligible to inherit all of the initializers from IceCreamSundae. It elected, however, to override theinit(flavor:,topping:) designated initializer, as follows:

class BananaSplit: IceCreamSundae {
override init(flavor: String = "Vanilla, Chocolate, Strawberry",
topping: String = "Caramel syrup") {
super.init(flavor: flavor, topping: topping)
scoops = 3 // Bannana split always has three scoops
}
}

The following code creates a BananaSplit object:

let split = BananaSplit(flavor: "Vanilla, Pineapple, Cherry")

Because it implemented at least one initializer, it won’t inherit any other designated initializers. It does, however, automatically inherit the convenience initializer init(special:) because that convenience initializer relies on the designated init(flavor:,topping:) initializer and that one was implemented in this subclass. The following code demonstrates using the inherited convenience initializer to create a banana split:

let sundaySplit = BananaSplit(special: .Sunday)

Required Initializers

And just to make initializers even more interesting—that is to say, complicated—you can declare that an initializer is required using the required keyword, as follows:

required init(flavor: String, scoops: Int) { ...

A required initializer must be overridden and re-implemented by a subclass. The subclass has the choice of just overriding the initializer or declaring it as required again. If you simply override the initializer, subclasses of your subclass are not required to implement the initializer again. If you re-require the initializer (using the require keyword again), the subclass of your subclass is required to implement it as well.

The most commonly encountered required initializer is the deserialization initializer in the NSCoding protocol you used in Chapter 19. The init(coder: NSCoder) initializer should be re-implemented in each subclass so that each can properly reconstruct the object from an archive data stream. Your subclass must re-implement init(coder: NSCoder), and you should mark it as required so that any subclasses of your class must do the same.

Closures

A closure is an object that encapsulates both a block of code and the variables it needs to execute. Think of a closure as a self-contained bundle of functionality that you can pass around like any other value. The name comes from the way a closure “closes over” the variables it references when it is created. The following code fragment demonstrates the general form of a closure:

var externalValue = 2
let closure = { (parameter: Int) -> ReturnType in
return codeThatDoesSomething(parameter+externalValue)
}

A closure is written like a free-floating block of code within a set of curly braces. Here are the salient points:

· Like a function, a closure may have parameters. The caller supplies these values when the closure is executed.

· Closure parameters do not have external names, and they cannot declare a default value.

· A closure’s return type must be specified. Use -> Void for closures that don’t return a value.

· The closure’s parameters and return type are declared before the in keyword. The code of the closure follows the in keyword. A closure with no parameters is written () -> ReturnType.

· A closure may make use of its parameters, variables it declares in its code block, and variables that exist outside the code block. The latter are “closed over” when the closure is created.

· Closures are often referred to as code blocks, hearkening back to similar functionality in Objective-C. Many other languages refer to this kind of functionality as a lambda.

Normally, a variable ceases to exist once it is out of scope. For example, a function parameter exists only for the lifetime of the function. When the function ends, so do its parameter variables (along with any local variables it created). In the following code, the parameter number gets created when the function is called and disappears again when it returns:

func inScope(number: Int) {
// code that does something with number
}

In the following version of inScope(_:), the function returns a closure to its caller. The closure captures the number parameter when it is created.

func inScope(number: Int) -> ((Int) -> Int) {
return { (multiplier: Int) -> Int in
return number * multiplier
}
}

When the function returns, its number parameter would normally ceases to exist. But since it was “closed over” by the closure, it now also exists in the scope of the closure as well and will continue to exist for the lifetime of the closure.

After the function returns, its reference to the number parameter goes away. The parameter is now, effectively, a private variable in the closure—since there are no other references to it. Each time you call the function, a new parameter variable is created, and a new closure captures that variable, as shown here:

let times5 = inScope(5)
let times3 = inScope(3)

We can demonstrate this by executing the two closures. You execute a closure by treating the closure variable as if it were a function, as follows:

var result = times5(7) // returns 35 (5*7)
result = times3(7) // returns 21 (3*7)

The two closures each multiply the supplied parameter with the value they captured in the earlier call to inScope().

In another scenario, consider the case where the closure captures a variable and that variable still exists. A closure captures a reference to a variable, not its value. (The distinction between values and references is discussed a little later in this chapter.) All the code, inside and outside of the closure, refers to the same variable. To demonstrate that, let’s create a persistent variable and a closure that captures it.

var multiplier = 3
let sharedVariable = { (number: Int) -> Int in
return number * multiplier
}

When you execute the closure, it multiplies its parameter value with the value of the captured multiplier variable, as follows:

result = sharedVariable(4) // returns 12 (4 * multiplier)

If you then modify the multiplier variable, the closure will use the modified value, as follows:

multiplier = 5
result = sharedVariable(4) // returns 20 (4 * multiplier)

Capturing self

Swift is full of shortcuts that allow you write only the code needed to express your intent. There are, however, a couple of places where Swift requires you to spell out the obvious so that it’s, well, obvious. Closures are one of those places. Consider the following view controller, animating the appearance of a label:

class LabelViewController: UIViewController {
@IBOutlet var label: UILabel!

override func viewDidAppear(animated: Bool) {
UIView.animateWithDuration(1.5, animations: { label.alpha = 1.0 })
}
}

Look at the closure carefully and tell me what variable it is “closing over.” (Hint, the answer is not label.)

That’s right, the correct answer is self. Whenever you refer to a property or function within a method, you’re implicitly referring to the instance variable or instance function of the context object. Within the context of the viewDidAppear(_:) function, the expression storyboardreally means self.storyboard, and the function call setEditing(true, animated: false) is really self.setEditing(true, animated: false).

The distinction in closures can be important. The previous closure captured the self variable (the reference to the view controller object) and not a reference to the specific UILabel object. This is critical because, as you’ve seen, a closure keeps a reference to the variables it captures.

Let’s say I create this closure but then immediately replace the label property with a different UILabel object. When the closure executes, it will use the new UILabel object because it captured self, not the original UILabel object. And this is why Swift won’t let you write the preceding code. You must write the closure as follows:

override func viewDidAppear(animated: Bool) {
UIView.animateWithDuration(1.5, animations: { self.label.alpha = 1.0 })
}

Swift requires you to write self.label, self.storyboard, and self.setEditing(true, animated: false) when writing a closure. This makes it abundantly clear that you’re capturing self and not label or storyboard.

Using Closures

Using closures couldn’t be easier. When you create a closure, it becomes a value—one you assign to a variable or pass as an argument. Your use of closures will likely begin as arguments. iOS provides many opportunities to pass a block of code to methods that will ultimately execute that closure to accomplish your tasks. Take almost any project in this book, and you’ll see closures in action. In Chapter 16, the code that adapted the display when it was resized passed two closures to the transition coordinator, as follows:

coordinator.animateAlongsideTransition( { (context) in self.positionDialViews() },
completion: { (context) in self.attachDialBehaviors() })

The animateAlongsideTransition(_:,completion:) method takes two parameters, both closures. The first closure is executed to animate your views during the transition, and the second closure executes after the transition is complete.

Notice that the parameter in each closure doesn’t have a type. That’s because Swift has a lot of shortcuts that let you write concise closures.

Closure Shortcuts

Swift allows you to use a number of shortcuts that simplify your closures.

· If the parameter and return types of the closure are implied by the parameter or the variable you’re assigning it to, you can omit those types.

· You can omit the parameter names and use their shorthand names.

· If the code for a closure can be written as a single return statement, you can write just the return expression.

· If the closure is the last parameter to a function call, you can use the trailing closure syntax.

The first shortcut simplifies the parameters of the closure. In a situation like the animateAlongsideTransition(_:,completion:) method, the description of the closure has already been established by the method. If you look at the method declaration, you’ll see something like the following:

func animateAlongsideTransition(
_ animation: ((UIViewControllerTransitionCoordinatorContext!) -> Void)!,
# completion: ((UIViewControllerTransitionCoordinatorContext!) -> Void)!) -> Bool

This function describes two parameters. Both expect a closure that has one parameter (of type UIViewControllerTransitionCoordinatorContext) and returns nothing (-> Void). The closure you pass as an argument to the call must match that description. Because Swift already knows the number and types of the parameters and the type the closure will return, Swift will fill those details in for you. All you have to do is name the parameters, as follows:

{ (context) in self.positionDialViews() }

The type of the context parameter and the return type of the closure are both implied. In this situation, you can also save a few keystrokes by tossing the parentheses, as follows:

{ context in self.positionDialViews() }

If a parameter is uninteresting, you can replace its name with an _ (underscore), as follows:

{ _ in self.positionDialView() }

Shorthand Parameter Names

If you don’t want to name the parameters, you can use their shorthand names: $0, $1, $2, and so on. If you do that, you can leave out the entire parameters clause at the beginning of the closure. Take the customActionWithDuration(_:,actionBlock:) method of SKAction as an example. This function is defined as follows:

func customActionWithDuration(_ seconds: NSTimeInterval,
actionBlock block: (SKNode!, CGFloat) -> Void)
-> SKAction

The second parameter is a closure that receives two parameters (an SKNode and a CGFloat). When you call this function, you can write the closure as follows:

SKAction.customActionWithDuration( 3.0,
actionBlock: {
(node, elapsedTime) in
if elapsedTime > 0.5 {
node.alpha = elapsedTime/3.0
}
})

The closure for the actionBlock parameter tests the elapsedTime parameter. If more than half a second has elapsed, it sets the node’s alpha proportionally based on the elapsed time. You could write the same code this way:

SKAction.customActionWithDuration( 3.0,
actionBlock: { if $1 > 0.5 { $0.alpha = $1/3.0 } } )

In the second example, the entire parameter declaration is omitted. Swift assigns the first parameter the shorthand name of $0, the second one $1, and so on. Use these shorthand names exactly as you would the named parameters.

Tip Limit your use of shorthand names to contexts where the meaning and type of the parameters is obvious. The second example is much less obvious than the first.

Single Expression Closures

There’s an even shorter form for closures that return a value. If the code for the entire closure can be expressed in a single return statement, you can omit the return statement and write the closure as an expression. This is particularly useful with methods like Swift’s sort(_:) andmap(_:) array functions. Let’s create a simple to-do item array with the following code:

struct ToDoItem {
let priority: Int
let note: String
}
var toDoList = [ ToDoItem(priority: 3, note: "Recycle ice cream cups"),
ToDoItem(priority: 1, note: "Buy ice cream"),
ToDoItem(priority: 2, note: "Invite friends over") ]

You can sort this array with the array’s sort(_:) function. This function accepts a single closure used to compare any two elements in the array. The closure receives two parameters (the two array elements to compare) and returns a Boolean value indicating whether the first (left) parameter should be before the second (right) parameter in the new order. (You’ll find examples of this in the Learn iOS Development Projects Ch 20 Closures.playground file.)

Let’s sort the array into priority order. Writing this closure with named parameters would look something like the following:

toDoList.sort( { (left, right) in return left.priority < right.priority } )

As you learned earlier, you can also write the closure using the shorthand parameter names, as follows:

toDoList.sort( { return $0.priority < $1.priority } )

But since the entire closure is a single return statement, Swift lets you get away with leaving out the return and writing the closure as just the expression. The following two statements are equivalent to the previous two:

toDoList.sort( { (left, right) in left.priority < right.priority } )
toDoList.sort( { $0.priority < $1.priority } )

Trailing Closures

Closures can get even shorter—well, maybe not the closure, but the syntax used to pass a closure as a parameter. If the last argument of a function call is a closure parameter, you can omit that argument and write the closure immediately after the function call. This is called a trailing closure. The SKNode class has an enumerateChildNodesWithName(_:,usingBlock:) method. The following example shows how you would call that method passing the closure as a regular argument:

let scene = SKScene()
scene.enumerateChildNodesWithName("firefly", usingBlock: {
(node, _) in
node.hidden = false
})

To write the same code using a trailing closure, omit the last parameter and follow the function call with the closure, as follows:

scene.enumerateChildNodesWithName("firefly") { (node, _) in node.hidden = false }

Again, this is particularly useful with functions like sort(_:). Using the earlier single expression example, you can ultimately write the sort function as follows:

toDoList.sort() { $0.priority < $1.priority }

This last example combines type inference, shorthand parameter names, single expression, and the trailing closure shortcuts.

Closure Variables

When you’re ready to store a closure in a variable or write a function the takes a closure as a parameter, you’ll need to write a closure type. A closure type is the signature of the closure (the part before the in keyword) inside parentheses. You write a variable that stores a closure as follows:

var closure: ((Int, String) -> Int)

This variable stores a closure that receives two parameters, an Int and a String, and returns an Int. Closure parameters don’t have external names or default values, so only the parameter types are listed. You can later assign a closure to this variable and later execute it as follows:

closure = { (number,name) in return 1 }
closure(7,"deborah")

Similarly, a function with a closure parameter is written as follows:

func closureAsParameter(key: String, master: ((String) -> Int)) {
unlockDoor(master(key))
}

Since the closure is the last parameter, this function is eligible for tailing closure syntax, like this:

closureAsParameter("The Key") { (key) in return key.hash }

Protocols

A protocol is a set of properties or methods that a class (or other type) can adopt. A protocol is, effectively, a promise to implement a specific set of features. Once your class fulfills that promise, your class can be used in any place that wants a type with that protocol. A class that adopts a protocol is said to conform to that protocol.

You declare a protocol much the way you would a class, using the protocol keyword. As a simple example, let’s create a Flavor protocol as follows. These, and other, examples can be found in the Learn iOS Development Projects Ch 20 Protocols.playgroundfile.

protocol Flavor {
var flavor: String { get }
func tastesLike(flavor otherFlavor: Flavor) -> Bool
}

This protocol requires a String property named flavor and a function named tastesLike(flavor:) that returns a Bool.

Your class adopts protocols by listing them after the superclass name (if any), as follows:

class IceCream {
var flavor: String = "Vanilla"
var scoops: Int = 1
}

class Sundae: IceCream, Flavor {
func tastesLike(flavor otherFlavor: Flavor) -> Bool {
return flavor == otherFlavor.flavor
}
}

In this example, the class Sundae is a subclass of IceCream and adopts the Flavor protocol. Adopting the protocol requires that it have a flavor property and a tastesLike(flavor:) function. The first was already inherited from its superclass, so implementing the function is all that’s required to adopt this protocol.

Note Objective-C can define protocols with optional properties and methods. Your class can decline to implement an optional method and will still conform to the protocol. Swift protocols do not have optional members.

The adopting class can fulfill a property requirement with either a stored or a computed property that is implemented, overridden, or inherited. A protocol doesn’t care how a class implements the interface, just that it does. Every property in a protocol is followed by either { get } or { get set }. Any property will satisfy the former. If the protocol states the property is { get set }, you must implement a mutable property.

Once Sundae has adopted Flavor, it can be used anywhere there’s a variable of type Sundae, IceCream, or Flavor. This allows unrelated classes to be treated as a common type, as long as all adopt the same protocol. In the following example, the completely unrelated class Tofualso adopts the Flavor protocol:

class Tofu: Flavor {
var flavor: String = "Plain"
var weight: Double = 1.0

func tastesLike(flavor _: Flavor) -> Bool {
// Tofu doesn't taste like anything else
return false
}
}

You can now declare variables and parameters of type Flavor and interchangeably use Tofu and Sundae objects as follows:

var dessert: Flavor = Sundae()
var chicken: Flavor = Tofu()
if dessert.tastesLike(flavor: chicken) { ...

Protocols are regularly used for delegates. A class will use a protocol to define the delegate’s interface and then declare a delegate property that can store any object that adopts that protocol. Just look at almost any Cocoa Touch class that has a delegate property.

Extensions

An extension adds properties or methods to an existing class (or other type). You can add methods and computed properties to almost anything, even classes you didn’t write. Back in Chapter 7, I told you that adding an imageView property to the MyWhatsit class was poor MVC design because the MyWhatsit class is a data model and the imageView was really a view method. With extensions, you can save your design while still adding an imageView property to MyWhatsit. Start with (a simplified version of) the original class, as follows:

class MyWhatsit {
var name: String
var location: String
var image: UIImage?
...
}

In a separate source file, you can create an extension to MyWhatsit that adds the extra method, as follows. The extension keyword is used to show that you are extending the existing class (or other type), not defining a new one.

extension MyWhatsit {
var viewImage: UIImage {
return image ?? UIImage(named: "camera")!
}
}

Now when you create MyWhatsit objects, they’ll all have a viewImage property, just as if you had defined that property in the original class.

var thing = MyWhatsit(name: "Robby the Robot")
detailImageView.image = thing.viewImage

This preserves MVC separation because the code that manages the data model is separate from the code that deals with view object responsibilities, even though both belong to the same object. In another program, you might reuse the MyWhatsit class in the absence of the extension, in which case the same objects won’t have a viewImage property.

Extensions are also handy for adding new functions to common classes. If you need an inKlingon property added to the String type, you can do that in an extension. Then you can write "Hello".inKlingon and Swift will perform your translation, as follows:

extension String {
var inKlingon: String { return self == "Hello" ? "nuqneH" : "nuqjatlh?" }
}
...
let greeting = "Hello"
println(greeting.inKlingon)

There are a couple of restrictions to extensions.

· An extension cannot add stored properties to an existing type. You can only add methods and computed properties.

· You cannot override an existing property or method in an extension.

Structures

A structure, or struct, in Swift is very much like a class. Unlike most other languages, a Swift structure has more in common with a class than what it doesn’t. Here’s an example of a Swift structure:

struct SwiftStruct {
var storedProperty: String = "Remember me?"
let someFixedNumber = 9
var computedProperty: String {
get {
return storedProperty.lowercaseString
}
set {
storedProperty = newValue
}
}

static func globalMethod() {
}
func instanceMethod() {
}
init(what: String) {
storedProperty = what
}
}

In Swift, a structure shares the following traits with a class:

· Can define stored properties (and stored properties can have observers)

· Can define computed properties

· Can define methods (instance functions)

· Can define global functions

· Can have custom initializers

· Can adopt protocols

· Can be augmented with extensions

There’s very little about these traits that differ—in either capability or syntax—between classes and structures. There are differences, both significant and minor.

· A structure cannot inherit from another structure.

· A structure is a value type, not a reference type.

· A structure does not have a deinit function.

· A global function in a structure is declared using the static keyword instead of the class keyword.

The first is probably the biggest difference. Every structure is an isolated type. Structures do not form an inheritance hierarchy, they cannot participate in subtype polymorphism, and you cannot test their type (which would be pointless because they can only be one type).

Structures are value types. I explain the difference between value and reference types later. For now, just know that a structure is a collection of stored properties. When you assign it to a variable or pass it as a parameter, the entire structure is duplicated. Changes made to a copy do not affect the original.

Like a class, Swift automatically creates a default initializer if all of its stored properties have default values. Unlike a class, a structure also gets a memberwise initializer—assuming it doesn’t define any custom initializers of its own. A memberwise initializer is an init method whose parameters are the names of all of its stored properties. The following example defines a structure with two stored properties. The code that follows creates two instance of the structure using its automatically generated initializers:

struct StructWithDefaults {
var number: Int = 1
var name: String = "amber"
}

let struct1 = StructWithDefaults()
let struct2 = StructWithDefaults(number: 3, name: "john")

Tuples

Tuples are ad hoc, anonymous, structures. Tuples are a convenient way to group a few related values together and treat them as a single value. You write a tuple by surrounding a list of values with parentheses, like this:

var iceCreamOrder = ("Vanilla", 1)

This statement creates a tuple containing two values, a String and an Int, assigned to the single variable iceCreamOrder. The following example creates the same kind of tuple but also gives its members names:

let wantToGet = (flavor: "Chocolate", scoops: 4)

The type of a tuple is simply the types of its content. You can assign a tuple to any variable with the same type, as follows:

iceCreamOrder = wantToGet

Note There is no practical limit on how many, or what kinds, of values you can include in a tuple. A tuple can be made from floating-point numbers, strings, arrays, objects, structures, enums, dictionaries, closures, and even other tuples.

Tuples are extremely handy for returning multiple values from a function. You used this in Chapter 14 for the score() function; it returned both the player’s numeric score and a flag indicating whether the game had been won, in a tuple. In the following example, the nextOrder()function returns a (String,Int) tuple. Play around with these examples in the Learn iOS Development Projects Ch 20 Tuples.playground file.

func nextOrder() -> (flavor: String, scoops: Int) {
return ("Vanilla", 4)
}
...
let order = nextOrder()

You access the individual values within a tuple much as you would a structure or class. If the tuple members were given names, you can address them as properties, like this:

if order.scoops > 3 {
println("\(order.scoops) scoops of \(order.flavor) in a dish.")
} else {
println("\(order.flavor) cone")
}

If a member of a tuple is anonymous (that is, they don’t have member names like the ones in iceCreamOrder), you can still address the member using its index. A tuple member index is a number, starting at 0, assigned to each member value in the tuple. You use an index just like a property name, as follows:

if iceCreamOrder.0 == "Chocolate" {
println("\(iceCreamOrder.1) scoops of the good stuff.")
}

And there’s a third way of addressing the individual values of a tuple. When you assign the tuple, you can decompose the tuple into individual variables, as shown here:

let (what,howMany) = nextOrder()
if howMany > 3 {
println("\(howMany) scoops of \(what) in a dish.")
} else {
println("\(what) cone")
}

The first statement declares two new variables, what and howMany. Each is assigned to one value from the tuple. This is a convenient way to assign names to tuples with anonymous members or gain more direct access to each value. If you’re not interested in a particular value, replace its variable name with an _ (underscore), just as you would ignore a parameter, as in let (what,_) = nextOrder().

Enumerations

An enumeration, or enum, assigns symbolic names to a set of unique literal values. You write an enumeration as a list of the symbols you want to define, as follows:

enum Weekday {
case Sunday
case Monday
case Tuesday
case Wednesday
case Thursday
case Friday
case Saturday
}

This defines a new type, Weekday, that can be used much like any other type. The enumeration defines seven unique values. The following statement defines a new variable (dueDay) of type Weekday and assigns it the value Thursday:

var dueDay = Weekday.Thursday

When Swift already knows the type of the variable or parameter, you can leave out the enumeration type name, like this:

dueDay = .Friday

This is particularly handy when passing an enumeration value in an argument.

Raw Values

Swift’s internal representation of enumeration values is opaque—computer-speak for “you don’t know and you can’t find out.” All you need to know is the values are unique and can be assigned to a variable of that enumeration type.

Optionally, you can define a relationship between the values in an enumeration and values in another type. This alternate value is called the enumeration’s raw value.

In the following example, an enumeration is defined that has seven values. Each value can be converted to and from a corresponding Int value.

enum WeekdayNumber: Int {
case Sunday = 0
case Monday
case Tuesday
case Wednesday
case Thursday
case Friday
case Saturday
}

The choices for a raw value are integer, floating-point number, string, or character. If you choose an integer type, a unique number is automatically assigned to each enumeration value, as shown earlier. You can, optionally, assign specific values to particular cases, as shown with Sunday.

An enumeration value can be converted to its raw value using its rawValue property. Conversely, an enumeration value can be created from a raw value using its init(rawValue:) initializer, both shown here:

let dayNumber = WeekdayNumber.Wednesday.rawValue
let dayFromNumber = WeekdayNumber(rawValue: 3)

Note The conversion from a raw value to an enumeration can fail; all enumeration values have a unique raw value, but not all raw values have a corresponding enumeration value. See the “Optionals” section for more about failable initializers.

The dayNumber is an Int with a value of 3. This was obtained by converting the WeekdayNumber.Wednesday value into its raw value. The dayFromNumber is a WeekdayNumber variable containing the value Wednesday, obtained by converting the raw value of 3 into aWeekdayNumber.

Raw values can also be strings or characters. In the following example, an enumeration with string raw values is defined. For non-integer values, you must provide a raw value for every case, and there can be no duplicates.

enum WeekdayName: String {
case Sunday = "Sunday"
case Monday = "Monday"
case Tuesday = "Tuesday"
case Wednesday = "Wednesday"
case Thursday = "Thursday"
case Friday = "Friday"
case Saturday = "Saturday"
}

Just as with numeric raw values, you can convert to or from the enumeration value. The following code prints the message “Reports are due on Monday.”

let reportDay: WeekdayName = .Monday
println("Reports are due on \(reportDay.rawValue).")

Associated Values

Each enumeration value can also store a tuple of other values, called associated values. This lets you bundle other interesting values with a specific enumeration value. For example, an enumeration of failure reasons might have associated values with information about each particular kind of failure. A .DocumentNotFound value might include the name of the missing document, while the .SessionExpired value might have the time the session ended.

When you add associated values to an enumeration, extra storage space is set aside for the additional tuples. Each tuple is paired with a specific enumeration value. That tuple can only be used when the enumeration variable is set to that value.

It’s easier to explain with an example. In the following code, several of the WeekdayChild enumeration values have associated values:

enum Sadness {
case Sad
case ReallySad
case SuperSad
}

enum WeekdayChild {
case Sunday
case Monday
case Tuesday(sadness: Sadness)
case Wednesday
case Thursday(distanceRemaining: Double)
case Friday(friends: Int, charities: Int)
case Saturday(workHours: Float)
}

The .Tuesday and .Saturday values store an associated floating-point number. The .Friday value stores two additional integer values. And the .Thursday value goes completely meta, storing another enumeration value. The other cases do not have associated values; treat those like any other enumeration.

Enumerations and their associated values are constructed through initializers. What follows are some examples, which you can also find in the Learn iOS Development Projects Ch 20 Enumerations.playground file.

let graceful = WeekdayChild.Monday
let woeful = WeekdayChild.Tuesday(sadness: .ReallySad)
let traveler = WeekdayChild.Thursday(distanceRemaining: 100.0)
let social = WeekdayChild.Friday(friends: 23, charities: 4)
let worker = WeekdayChild.Saturday(workHours: 90.5)

Tip The external names for associated value tuple members are optional. You can leave them out and just use the values, as in WeekdayChild.Friday(23,4).

Oddly, you can’t access associated values directly. The only mechanism for retrieving them is through a switch statement, like this one:

var child = traveler
switch child {
case .Sunday, .Monday, .Wednesday:
break
case .Tuesday(let mood):
if mood == .ReallySad {
println("Tuesday's child is really sad.")
}
case .Thursday(let miles):
println("Thursday's child has \(miles) miles to go.")
case .Friday(let friendCount, let charityCount):
println("Friday's child has \(friendCount) friends.")
case .Saturday(let hours):
println("Saturday's child is working \(hours) hours this week.")
}

You obtain the associated values by decomposing the tuple using let statements within each switch case, as shown earlier. The reason for this odd mechanism is that an enumeration value could, potentially, contain any of the possible enumeration values. But the associated values are only valid when it is set to a specific enumeration value. The switch case ensures that access is only granted to the associated values for that specific enumeration value.

Extended Enumerations

Enumerations are full-blown types, like classes and structures. An enumeration can define computed properties and have static and instance methods. It can adopt protocols, can be extended by extensions, and can have custom initializers. You cannot add stored properties; use associated values for that. The following is an enumeration with computed properties, methods, and a special initializer:

enum WeekdayNumber: Int {
case Sunday = 0
case Monday
case Tuesday
case Wednesday
case Thursday
case Friday
case Saturday

var weekend: Bool { return self == .Sunday || self == .Saturday }
var weekday: Bool { return !weekend }
init(random: Bool) {
if random {
nextWeekDayNumber = Int(arc4random_uniform(7))
}
self = WeekdayNumber(rawValue: nextWeekDayNumber)!
nextWeekDayNumber++
if nextWeekDayNumber > WeekdayNumber.Saturday.rawValue {
nextWeekDayNumber = WeekdayNumber.Sunday.rawValue
}
}
func dayOfJulienDate(date: NSTimeInterval) -> WeekdayNumber {
return WeekdayNumber(rawValue: Int(date) % 7 + 2)!
}
}
var nextWeekDayNumber: Int = WeekdayNumber.Monday.rawValue

When writing code that runs in the context of an enumeration, the self variable represents its current value. You establish the enumeration’s value in the initializer by assigning a value to self. You’d use any of these features just as you would with a structure or object, as follows:

let today = WeekdayNumber(random: true)
if today.weekend {
clock.alarm.enabled = false
}

Numeric Values

Now you’re getting down to the simplest types, but there might still be a few surprises waiting for you. Swift has integer and floating-point numeric types. You’ve been using these throughout this book.

Integer types come in a variety of sizes and signs: Int, UInt, Int8, UInt8, Int16, UInt16, Int32, UInt32, Int64, and UInt64. You’ll find examples of these in the Learn iOS Development Projects Ch 20 Numbers.playground file.

The vast majority of the time you should use Int, occasionally UInt, and almost nothing else. You’ll understand why shortly. The rest of the types are useful only when dealing with specific data sizes, such as binary message formats.

Floating-point numbers come in two flavors: Float and Double. Float is always 32 bits, and Double is always 64-bits.

When running a Swift program on a 32-bit processor, the Int and UInt types are 32 bits wide (equivalent to Int32 and UInt32). When compiled for a 64-bit processor, they are both 64 bits wide. The iOS Foundation library defines the CGFloat type. It is 32-bits (Float) when compiled for 32-bit processors and 64-bits (Double) on 64-bit processors. The Cocoa Touch framework makes extensive use of CGFloat.

Implicit Type Conversion

Swift, quite unlike most computer languages you’ve probably encountered, has no implicit type conversion. When you assign a variable, pass a value in an argument, or perform an operation on two values, the values you supply must exactly match the type expected (with only a few exceptions that I’ll get to in a moment). The following example demonstrates this:

var signed: Int = 1
var unsigned: UInt = 2
var double: Double = 3.0
var float: Float = 4.0
signed = unsigned // <-- invalid
unsigned = signed // <-- invalid
double = float // <-- invalid

One of the reasons Swift can infer types—relieving you from typing them over and over again—is because there’s never any ambiguity about what type a number or expression is, and there’s never any possibility of accidentally losing numeric precision through an assignment or conversion. It also means you must intentionally convert any values that aren’t the correct type.

This is the reason for my advice to use Int as much as possible. If all your integers are Int, you won’t have any conversions to do.

If you have one type and need another, you must explicitly create the type you need. You create integer and floating-point types exactly as you do objects, structures, and enumerations. The following code fixes the impedance mismatch shown earlier by creating new, compatible, types:

signed = Int(unsigned)
unsigned = UInt(signed)
double = Double(float)

The Int type has initializers that accept every other integer and floating-point type, and vice versa. Generally, these constructors will prevent loss of data by throwing an exception if the conversion cannot be completed. The following example results in an error because the integer value of 300 can’t be represented by an 8-bit integer:

let tooBigToFit = UInt8(300) // error

The exceptions are the integer initializers from floating-point values. These initializers will silently truncate the fractional portion of the value. The expression Int(2.6) will be the integer value 2.

Numeric Literals

Numeric literals, by contrast, are much more flexible. Swift recognizes a variety of number formats, as shown in Table 20-2.

Table 20-2. Literal Number Formats