Day 04
Day 04 êŽë š
Complex data types, part 2
Today weâre going to finish our look at data types by examining type annotation, which is Swiftâs way of letting us dictate exactly what data type each variable and constant should be. Once thatâs done weâll summarize whatâs covered, then try another checkpoint so you can evaluate what youâve learned so far.
I know, youâre probably sick of data types at this point, but as Eric Raymond said, âgood data structures and bad code works a lot better than the other way around.â
Today youâll learn about type annotation, then go through the summary and checkpoint. Thereâs some optional extra reading that I recommend you read, along with a short test to help make sure youâve understood what was taught.
Today ought to take you a lot less than an hour to complete, but thatâs okay â day 13 will probably take more than an hour, so it all balances out!
1. How to use type annotations
1. How to use type annotations
Swift is able to figure out what type of data a constant or variable holds based on what we assign to it. However, sometimes we donât want to assign a value immediately, or sometimes we want to override Swiftâs choice of type, and thatâs where type annotations come in.
So far weâve been making constants and variables like this:
let surname = "Lasso"
var score = 0
This uses type inference: Swift infers that surname is a string because weâre assigning text to it, and then infers that score is an integer because weâre assigning a whole number to it.
Type annotations let us be explicit about what data types we want, and look like this:
let surname: String = "Lasso"
var score: Int = 0
Now weâre being explicit: surname must be a string, and score must be an integer. Thatâs exactly what Swiftâs type inference would have done anyway, but sometimes it isnât â sometimes you will want to choose a different type.
For example, maybe score is a decimal because the user can get half points, so youâd write this:
var score: Double = 0
Without the : Double part Swift would infer that to be an integer, but weâre overriding that and saying itâs definitely a decimal number.
Weâve looked at a few types of data so far, and itâs important you know their names so you can use the right type annotation when needed.
String holds text:
let playerName: String = "Roy"
Int holds whole numbers:
var luckyNumber: Int = 13
Double holds decimal numbers:
let pi: Double = 3.141
Bool holds either true or false:
var isAuthenticated: Bool = true
Array holds lots of different values, all in the order you add them. This must be specialized, such as [String]:
var albums: [String] = ["Red", "Fearless"]
Dictionary holds lots of different values, where you get to decide how data should be accessed. This must be specialized, such as [String: Int]:
var user: [String: String] = ["id": "@twostraws"]
Set holds lots of different values, but stores them in an order thatâs optimized for checking what it contains. This must be specialized, such as Set<String>:
var books: Set<String> = Set(["The Bluest Eye", "Foundation", "Girl, Woman, Other"])
Knowing all these types is important for times when you donât want to provide initial values. For example, this creates an array of strings:
var soda: [String] = ["Coke", "Pepsi", "Irn-Bru"]
Type annotation isnât needed there, because Swift can see youâre assigning an array of strings. However, if you wanted to create an empty array of strings, youâd need to know the type:
var teams: [String] = [String]()
Again, the type annotation isnât required, but you still need to know that an array of strings is written as [String] so that you can make the thing. Remember, you need to add the open and close parentheses when making empty arrays, dictionaries, and sets, because itâs where Swift allows us to customize the way they are created.
Some people prefer to use type annotation, then assign an empty array to it like this:
var cities: [String] = []
I prefer to use type inference as much as possible, so Iâd write this:
var clues = [String]()
As well as all those, there are enums. Enums are a little different from the others because they let us create new types of our own, such as an enum containing days of the week, an enum containing which UI theme the user wants, or even an enum containing which screen is currently showing in our app.
Values of an enum have the same type as the enum itself, so we could write something like this:
enum UIStyle {
case light, dark, system
}
var style = UIStyle.light
This is what allows Swift to remove the enum name for future assignments, so we can write style = .dark â it knows any new value for style must be some kind UIStyle
Now, thereâs a very good chance youâll be asking when you should use type annotations, so it might be helpful for you to know that I prefer to use type inference as much as possible, meaning that I assign a value to a constant or variable and Swift chooses the correct type automatically. Sometimes this means using something like var score = 0.0 so that I get a Double.
The most common exception to this is with constants I donât have a value for yet. You see, Swift is really clever: you can create a constant that doesnât have a value just yet, later on provide that value, and Swift will ensure we donât accidentally use it until a value is present. It will also ensure that you only ever set the value once, so that it remains constant.
For example:
let username: String
// lots of complex logic
username = "@twostraws"
// lots more complex logic
print(username)
That code is legal: weâre saying username will contain a string at some point, and we provide a value before using it. If the assignment line â username = "@twostraws" â was missing, then Swift would refuse to build our code because username wouldnât have a value, and similarly if we tried to set a value to username a second time Swift would also complain.
This kind of code requires a type annotation, because without an initial value being assigned Swift doesnât know what kind of data username will contain.
Regardless of whether you use type inference or type annotation, there is one golden rule: Swift must at all times know what data types your constants and variables contain. This is at the core of being a type-safe language, and stops us doing nonsense things like 5 + true or similar.
Important: Although type annotation can let us override Swiftâs type inference to a degree, our finished code must still be possible. For example, this is not allowed:
let score: Int = "Zero"
Swift just canât convert âZeroâ to an integer for us, even with a type annotation requesting it, so the code just wonât build.
1. How to use type annotations - Additional
- Optional: Why does Swift have type annotations?
- Optional: Why would you want to create an empty collection?
- Test: Type annotations
2. Summary: Complex data
2. Summary: Complex data
Weâve gone beyond simple data types now, and started looking at ways to group them together and even create our own using enums. So, letâs recap:
- Arrays let us store lots of values in one place, then read them out using integer indices. Arrays must always be specialized so they contain one specific type, and they have helpful functionality such as
count,append(), andcontains(). - Dictionaries also let us store lots of values in one place, but let us read them out using keys we specify. They must be specialized to have one specific type for key and another for the value, and have similar functionality to arrays, such as
contains()andcount. - Sets are a third way of storing lots of values in one place, but we donât get to choose the order in which they store those items. Sets are really efficient at finding whether they contain a specific item.
- Enums let us create our own simple types in Swift so that we can specify a range of acceptable values such as a list of actions the user can perform, the types of files we are able to write, or the types of notification to send to the user.
- Swift must always know the type of data inside a constant or variable, and mostly uses type inference to figure that out based on the data we assign. However, itâs also possible to use type annotation to force a particular type.
Out of arrays, dictionaries, and sets, itâs safe to say that youâll use arrays by far the most. After that comes dictionaries, and sets come a distant third. That doesnât mean sets arenât useful, but youâll know when you need them!
3. Checkpoint 2
3. Checkpoint 2
Now that youâve met arrays, dictionaries, and sets, I want to pause for a moment to give you chance to solve a small coding challenge. Itâs not designed to trip you up, but instead to encourage you to stop for a while and think about what youâve learned.
This time the challenge is to create an array of strings, then write some code that prints the number of items in the array and also the number of unique items in the array.
Iâll provide some hints below, but please take the time to think about a solution before you read them. Trust me: forgetting what youâve learned then re-learning it actually makes it sink in deeper!
Still here? Okay, here are some hints:
- You should start by creating an array of strings, using something like
let albums = ["Red", "Fearless"] - You can read the number of items in your array using
albums.count. countalso exists for sets.- Sets can be made from arrays using
Set(someArray) - Sets never include duplicates.
Tip
Even though the checkpoint doesnât ask much, donât be surprised if you spend some time kind of staring at the screen wondering what to do. That isnât a bad sign â in fact, Iâd say itâs a good sign. I firmly believe there is no learning without struggle, so donât be afraid to fight for it!
