100 Days of Swift

Day 8

Today was the second day of functions, with a focus on providing default values for parameters and error handling. Default parameters are useful when they seem like they would be useful. When there is a sensible default but sometimes it would also make sense to override that default. To set the default, simply assign the parameter a value when defining it in the function. Error handling is a little bit more complicated. A throwing function is a function that can throw errors. I learned you can create your own errors by making an enum that conforms to Error. A throwing function must be marked as throws but is not required to throw an error. A throwing function can only be called inside of a do block which is followed by a catch block. The catch block can handle specific errors or be a default, or you could have both. You must use the keyword try to call the throwing function.

100 Days of Swift

Day 7

Day seven is about functions. I know how functions work from Python, so nothing conceptually is too hard. However, like many things, the syntax for Swift is different. The curly braces were a little odd to get used to, but they clearly define where things start and end which is useful. One major difference is requiring an argument label when adding arguments to your function. If my function timesTwo takes an integer parameter I will label it func timesTwo(number: Int) { function body } where number is my chosen label and Int is the type of the parameter. To call my function later I would use timesTwo(number: <an integer>) instead of simply timesTwo(<an integer>). This is probably more helpful than not, especially because Xcode is helpful when autocompleting code and will suggest all required arguments. You can use an underscore before the parameter to not require the label when calling the function. Swift requires the return type to be explicitly specified when returning a value from a function using an arrow -> and then the return type. I learned to use tuples when returning multiple values from a function.

100 Days of Swift

Day 6

Loops! All there is to know about loops. For loops, which iterate a finite number of times, and while loops, which iterate while true. All easy stuff but I learned a couple Swift specific syntax things, such as using an underscore as the loop variable in a for loop if the loop variable is never used in the loop body. Using break in a loop will stop the current iteration and immediately move to the code after the loop. Using continue will stop the current iteration but the loop will, well, continue. I also learned the closed and half-open range operators. Closed range x...y is all numbers between x and y, inclusive. Half open range does not include the upper bound x..>y. Half open range is useful for iterating over arrays where the lower bound is zero and the upper bound is array.count.

100 Days of Swift

Day 5

This day was all about conditions. It started with super super basic if, else, and else if statements. Nothing new in that section at all. AND in Swift is && and OR is ||. Then we got to switch, which is new to me. Using switch avoids a long list of else if statements and helps prevent errors. I originally thought switch was only for enums, but it can actually be used on other data types as well. Swift switches must check all values, which is what helps prevent errors. They run checks one at a time from the top until it matches a case and then stops checking after that. You can force it to keep checking by using fallthrough (which is very rarely used). Using default: you can provide a default case. The default case will always be last in the list. I also briefly relearned the ternary conditional operator, which is basically an if else statement combined into one line of code. The syntax is condition ? If true : If false. The ternary operator is not used much in normal code because it is generally harder to read than using if else, but it is useful and sometimes necessary in SwiftUI.

100 Days of Swift

Day 4

Today was about type annotations, or the syntax of explicitly specifying the type of a variable or expression. Swift will infer the type if possible, for example in the case var name = "Fletcher" Swift infers that the variable name has the type String. Optionally, you can include a type annotation: var name: String = "Fletcher". This is not needed unless there is potential for Swift to infer the wrong type. In the example var rating = 0 Swift will infer that the variable rating has the type of Int while you may have wanted to increment by .5 instead. Because rating is of the type Int rating = 2.5 is not valid code. We can fix this by using a type annotation. var rating: Double = 0 explicitly tells Swift that rating is a floating point number and not an integer. Another way to solve this problem with type inference instead of type annotation is var rating = 0.0 which Swift will infer correctly. Another use for type annotation is for an empty constant/variable that has not yet been assigned a value. let age: Double creates a constant age of the type Double and allows a value to be passed in later. The bottom line is Swift always has to know the type of your constants and variables. "The golden rule of Swift." In python 5 + True is legal code and returns 6. In Swift this is not legal code which does seem to make more sense. It is not possible to "fool" Swift by using type annotation, for example with the line var scores: Int = "Zero". Swift knows that scores must contain an Int and that "Zero" is a string, and this code will not build. Enums are a way to create your own type, and type annotation works the same as with any other type.

100 Days of Swift

Day 3

Day three brings "complex data types". I am still solidly in my comfort zone with the basic functionality of arrays and dictionaries. I learned that if you call .reversed on an array Swift doesn't actually reverse it, it just remembers that you want it reversed. Dictionaries use brackets [ ] instead of the curly braces { } from Python. If you want a default value instead of nil when you call a dictionary key that doesn't exist you can use dictionary["key", default: <your default here>]. Dictionaries do not have to store only strings: they can have integer keys for Boolean values for example. I also learned about sets and enums. While I did know what both of these were, and could have written out examples, it was good to learn the Swift specific syntaxes. Sets are not ordered and do not have duplicates. To add to a set, use set.insert() and not append() like an array. Sets are good if you do not want to store duplicates, or if you want to look up items quickly. Sets are very optimized for speed compared to arrays. Enums are another very fast data type that is new to me in Swift. They "enumerate" different cases that exist, which allows for safer code: Xcode will give an error if you try to call something not in the enum. For example, an enum WeekendDays with cases Saturday and Sunday will not allow me to set a variable to WeekendDays.Friday or even WeekendDays.Sundayy (a typo). The enum is also much faster than using the string "Sunday".

100 Days of Swift

Day 2

Today was a short day: I learned about Booleans and basic string functionality like concatenation and interpolation. The concepts are identical to Python, but Swift string interpolation obviously does not use an f-string or other Python solution, and instead uses a backslash with parentheses. I learned that the word Boolean comes from some random guy named George Boole! That was new to me. String interpolation is powerful, and is useful to dynamically show data to the end user. I briefly learned that custom string interpolation is possible, but I couldn't write my own from memory. Essentially, "I'm \(42)" normally returns "I'm 42", but a custom extension could instead make that read "I'm forty-two". This uses the NumberFormatter() which I haven't explored yet, and a .spellOut modifer of some kind. I completed Checkpoint 1 which was a very very simple Celcius to Fahrenheit converter. Yes, it only goes one way—that was the assignment!

100 Days of Swift

Day 1

I am starting on a 100 day journey through the "100 Days of SwiftUI" course by Paul Hudson of Hacking With Swift. It is WWDC right now, so I expect the latter parts of the course to change, but I am dedicated to learning as much as I can about the basics of Swift and SwiftUI before tackling the new stuff that is currently in beta. The only requirements of this generously free course are to spend an hour a day learning/watching/coding Swift (following his structure), and posting somwhere about what you learned. I thought it would be a great way to learn how to make a better website at the same time. At the moment I am typing into a .html document in VSCode and I hope that at the end of the 100 Days of Swift I also will have a new and improved website. For now, it's typing on one wordwrapped line between a paragraph tag.

I learned about variables, constants, strings, floating point numbers, and various other things I already knew from Python. I am dedicated to learning Swift the right way though, which means relearning some concepts while I internalize the Swift specific syntax. My biggest takeaway was understanding what a type-safe language is and why Swift is one of them.