Swift-Language on blog.iankulin.com

Things I love about Swift after a week of JavaScript

Fri, 06 Jan 2023 00:00:00 +0000

So, a week into JavaScript, what am I missing? The techie in me wants to say things like Automatic Reference Counting, but actually, at my junior level, I don’t run into memory management issues on the day-to-day, so what really do I miss?

Determinism

When I build an iOS app, it’s frozen in time. The functions inside are always going to stay the same. There might be a future version of iOS that won’t run it, but as long as it runs, any pure functions inside it will return the same value. The process of compiling it locks that in. Likewise, any libraries that are complied with it.

As an interpreted language, that is not true for JavaScript. It can be interpreted differently. It might run differently on different versions of a browser, or browsers from different developers. For example, it would be possible to write a function that adds 1+1 that has a different result on the current version of the Opera Mini browser to Chrome do to the different way it deals with const.

It’s a fair point to say this also does not affect me on the day-to-day, but it does worry me that something I put out there might fail unpredictably in the future. I guess web assembly fixes this, but then I could be writing in Swift!

IDE

I really love VS Code, it makes me feel differently (in a good way) about Microsoft. It’s fun to write code in, and has a amazing extensions that provide all sorts of good experiences, but it’s not a complete IDE. Likely there’s things I can set up to get closer to debugging in VS Code while running my apps in a browser and I just haven’t figured them out yet. When I’m just playing with JS using node is a good solution but I haven’t arrived at a smooth solution for browser. Currently I’m using lots of console.log()s and the developer console in the browsers.

It’s fair to say Swift developers don’t universally love the Xcode experience, and there is definitely room to improve the extension environment, but it is a complete package for developing iOS apps.

Deprecated = Deleted

When Swift kills off an old language feature in a big number version change, it stays dead. It’s not there any more, it haunt’s no one. That’s not possible with an interpreted language with millions of installed apps. Browsers have to support bad old ideas in JavaScript basically forever. I have to have CanIUse open in a tab (although I guess there’s a VS Code extension for that!).

In JavaScript’s favour

I love the low barrier to entry to JavaScript. Web development is open to anyone with an internet connection and a device. No MacBook, no Apple Developer subscription, no iPhone needed. Most anyone wanting to try it can just open the console in their browser.

In theory an interpreted language has the advantage of not needing the build step. When I first encountered Ruby and Python this was part of their charm for me. This does apply to JavaScript - you can just pull up the console and start playing. In the intervening years, compiled languages have made up this space a bit though, so it’s not the big selling point it used to be. Swift in Xcode is compiled somehow as you type so you’re seeing errors flagged as they occur. Building the little apps I’ve written is very quick, and tools like Playgrounds fill part of this need.

Codable & JSON

Sun, 30 Oct 2022 00:00:00 +0000

If we mark a type with the protocol Codable, we’re specifying that this type has the capability of having it’s properties encoded to some format, and decoded back again.

So far in the #100Days this has been used to write and read data in UserDefaults, and to encode an object to send it as a URLRequest, then receive data back and create a new object from it. It’s a handy, powerful feature baked into Swift that just requires the developer to ensure any types that need this functionality comply with the Encodable and Decodable protocols that make up the Codable.

I assume there’s some magic (by magic I guess I mean code created during the compile/build process - or perhaps a language feature that lets us enumerate the property names of a type? ) that allows Swift to step through each property in a composite type in order to encode or decode via the encoder/decoder

Making a type Codable

For simple situations, you just add the Codable protocol to your type. If all the properties inside that type are Codable, then your struct/class will be to. All the straightforward built in types are.

struct Chair: Codable {
 var name: String = ""
 var legs: Int = 4
}

Since String and Int are codable, the Chair struct will be as well. I’ll deal with how you fix a type that’s not codable another day.

Encoding

To encode our data we need an encoder. We’ll use the Foundation JSONEncoder, but there are others such as XML and so on.

struct Chair: Codable {
 var name: String = ""
 var legs: Int = 4
}

let stool = Chair(name: "Stool", legs: 3)
let encoder = JSONEncoder()

do {
 let jsonData = try encoder.encode(stool)
 print(String(data: jsonData, encoding: .utf8)!)
} catch {
 print("Encoding Error")
}

This prints out:

{"name":"Stool","legs":3}

So the property names are used to build our data. The “data” returned by the JSONDecoder is a UTF8 string - this is specified by the JSON standard, and that’s why the print above is not just print(jsonData).

Decoding

// use # to delimit a string that contains double quotes
let jsonString = #"{"name":"Kitchen chair","legs":4}"#

// convert our Swift string into the UTF-8 data type expected
let data = Data(jsonString.utf8)

let decoder = JSONDecoder()
let newChair = try decoder.decode(Chair.self, from: data)

print(newChair.name)
// Kitchen chair

Wrap up

I’ve used the simplest cases here to show how the basics work, but there’s a couple of common situations that require a bit more work. The most common is that the JSON you are trying to decode has non-swifty keys. It’s common for JSON keys to be snake_case rather than camelCase. Another issue is if our type needs a bit of work to make it codable. There’s some overlap in these situations that well look at another time.

Moonshot Challenges

Fri, 14 Oct 2022 00:00:00 +0000

Another few coding challenges at the end of a tutorial app in the 100 Days of SwiftUI course. The app is a sort of information app - composed of navigation views going down into more detail about the Apollo space missions. The most exciting revelation for me was how straightforward it is to pull JSON into your apps data structures.

Challenge 1

Add the launch date to MissionView, below the mission badge. You might choose to format this differently given that more space is available, but it’s down to you.

Adding a text view, but also another computed property to the Mission type to retrieve a longer version of the date string.

Challenge 2

Extract one or two pieces of view code into their own new SwiftUI views – the horizontal scroll view in MissionView is a great candidate, but if you followed my styling then you could also move the Rectangle dividers out too.

One of the SwiftLint rules is about the length of views, and I recall Paul Hegarty saying something in the first couple of CS193p lectures about views needing to be kept short. I never know the pros and cons of extracting parts of them as a function or as another struct. And if I do extract them as a struct, it always seems odd to me to just be able to “call” a struct exactly as a function - although since this is declarative programing and we’re just describing a view I guess it’s fine.

For this change, I pulled it out the crew view and a custom divider as structs. I had to move a baby data struct out of the MissionView namespace to make it available to the new view. An alternative have been keeping the new struct also in the main view, but I don’t love doing that too much. The trade off here was the potential advantages of reusing the new sub-view somewhere else, ease of testing and shorter views, vs polluting the namespace and putting things in the global app scope that do not need to be there. Deciding factor for me in this case was just ease of understanding the code.

source

Challenge 3

For a tough challenge, add a toolbar item to ContentView that toggles between showing missions as a grid and as a list.

It’s some combination of unsettling and pleasing if Paul thinks something should be hard and I knock it out quickly. I never know if I’ve missed some crucial point or I’m just getting the hang of things.

For this one I pulled out all the code that showed the grid inside a ScrollView(), duplicated it and edited the new one into a “list” by deleting the enclosing GridView(), changing a couple of VStacks to HStacks and tweaking some sizes. I added a @State variable for showing the grid, and a SF Symbol to the toolbar to swap between the views.

We’ve previously been advised to avoid an if statement to chose between two views as a state changes since it causes the new view to be created (rather than a ternary operator on a modifier or similar), but there’s no real way of avoiding it here - the user is literally asking us for a new view - so that goes into the main view where I extracted the other code from.

source

When I read down into the hints after completing this, Paul talks about some gotchas with List() - which I hadn’t used, so I’ll be interested to see his wrap up to see if a List would have been better than my solution.

Using Swift's map

Thu, 13 Oct 2022 00:00:00 +0000

In Day 39’s Moonshot tutorial app, Paul uses .map on an array without much comment about what’s going on. I assume this might be a common concept in modern languages, but it was new to me.

First, here’s Paul’s code

 init(mission: Mission, astronauts: [String: Astronaut]) {
 self.mission = mission

 self.crew = mission.crew.map { member in
 if let astronaut = astronauts[member.name] {
 return CrewMember(role: member.role, astronaut: astronaut)
 } else {
 fatalError("Missing \(member.name)")
 }
 }
 }

Mission here contains an array of crew which is a struct with two strings, one of them being name, but self.crew (which belongs to the view we’re in) is an array of CrewMember which is a struct with a role: String and another struct astronaut. That sounds confusing, but essentially, an array of one type is being processed to return an array of another type where there’s a 1:1 relationship between the elements of each array.

That’s what map does - it works through a collection, and uses the code in a closure to act on each element to transform it, then adds it to the array to be returned.

Let me try to make it clearer with a simpler example. Time to open a Playground. Let’s map an array of integers into an array of strings:

let intArray = [0, 55, 21, 13]
var stringArray = [String]()

stringArray = intArray.map{ "\($0)"}

print(stringArray)
// ["0", "55", "21", "13"]

$0 is a stand in for each element. This is a common Swift feature but this variable can be named for clarity if desired:

let intArray = [0, 55, 21, 13]
var stringArray = [String]()

stringArray = intArray.map{ number in "\(number)"}

print(stringArray)
// ["0", "55", "21", "13"]

If we didn’t have map, we could do it the long way, something like this.

let intArray = [0, 55, 21, 13]
var stringArray = [String]()

intArray.forEach {
 stringArray.append("\($0)")
}

print(stringArray)
// ["0", "55", "21", "13"]

or, going back even further in time:

let intArray = [0, 55, 21, 13]
var stringArray = [String]()

for number in intArray {
 stringArray.append("\(number)")
}

print(stringArray)
// ["0", "55", "21", "13"]

So the .map method on a sequence returns an array of values built by applying to the passed closure to each element of the sequence.

Paul’s code at the top steps through the mission.crew array which contains the crews names as strings, then attempts to look them up in the astronauts dictionary. If it finds them, it adds them (as a struct) to the crew array.

Ranges

Sun, 25 Sep 2022 00:00:00 +0000

I wondered aloud, in a previous post, about the differences in writing a range as

 ForEach(1..<21) {
 Text(String($0))
 }

versus

 ForEach(1...20) {
 Text(String($0))
 }

And that’s been answered in in one of the Day 34 articles. It sounds like older versions of Swift might not have allowed the second version.

How to upgrade XCode and Swift

Sun, 18 Sep 2022 00:00:00 +0000

With the September release of XCode 14 and Swift 5.7 it was time for my first update - I looked in “About” for an update link but there wasn’t one - so if you’re as dense as me, the tip is to head to the Mac App Store and have a look at the Updates page.

Your current XCode version can, of course be found in the XCode | About dialogue. Mine was on 13.4.1. There’s a couple of ways of finding the Swift version - If you’ve got an XCode project open, click on the .xcodeproj in the explorer,and have a look in Build Settings for Swift Compiler - Language for the major version.

Or for a bit more accuracy, try xcrun swift -version at the command line. I got a few errors, then the version 5.6.1

I won’t bang on about the changes for XCode or Swift since that’s already been done well elsewhere, and the Swift changes are mostly beyond my expertise level.

Swift enums

Mon, 12 Sep 2022 00:00:00 +0000

I’ve started on the refactoring for Rock, paper, scissors. One of the things I didn’t like was using Ints to signal which shape (I’m calling the rock, or paper, or scissors hand shape a shape) was being handed around. The Int I was using was also the index into an array of the emoji’s - so if I did an off-by-one I was risking an out of bounds on the array.

I’m pleased with this solution:

If you’re a refugee from C, there’s a lot happening here:

1 - In C enums are actually int’s inside, and you can mess with which int goes with which value. In Swift, they can be any type, but the type is specified when you define the enum. They are extracted with .rawvalue

2 - The Swift String type is a beast. Yes it does emojis, and a lot of other very cool unicode stuff that has a cost.

3 - enums can have methods. I know right?

When I read the Swift book, I felt it was a travesty against nature for enums being allowed to have methods, but the code above felt like the most natural thing ever. I must be acclimatising.

Apart from eliminating the array out of bounds possibility, this also made the code more readable, and meant that I could remove the default case from all my switch statements.

source

I might not be happy with the name of this type - Shape. I have spend a bit of time thinking about it, and even looked up Rock Paper Scissors on Wikipedia to see what terminology they used. It’s meant to represent the shape of the hands made by the players in each round of the game. It felt unclear enough that I added a comment to make it clearer - a sure sign it’s not. It may change to FingerShape when I do the next lot of refactoring.

.self in ForEach

Wed, 07 Sep 2022 00:00:00 +0000

I’m on Day 25 of Hacking With SwiftUI, and Paul is making a point about how SwiftUI can loop over an array to build a view. He starts with this:

let agents = ["Cyril", "Lana", "Pam", "Sterling"]
VStack {
 ForEach(0..<agents.count) {
 Text(agents[$0])
 }
}

But then proposes an alternative:

let agents = ["Cyril", "Lana", "Pam", "Sterling"]
VStack {
 ForEach(agents, id: \.self) {
 Text($0)
 }
}

He explains the use of \.self here by saying

So, we come back to how Swift can identify values in our array. When we were using a range such as 0..<5 or 0..<agents.count, Swift knew for sure that each item was unique because it would use the numbers from the range – each number was used only once in the loop, so it would definitely be unique.

In our array of strings that’s no longer possible, but we can clearly see that each value is unique: the values in ["Cyril", "Lana", "Pam", "Sterling"] don’t repeat. So, what we can do is tell SwiftUI that the strings themselves – “Cyril”, “Lana”, etc – are what can be used to identify each view in the loop uniquely.

I’m having a couple of problems with this.

Grumble One

The first is that Swift can’t really use the “strings themselves”. So this doesn’t work:

ForEach(agents, String($0)) {
 Text($0)
}

It complains that there’s no initialiser to take those arguments. So \.self must be something fancier. This is something I can presumably investigate by looking at the initialisers for ForEach.

Grumble Two

And the second grumble is that the first formulation ForEach(0..<agents.count) throws a compiler warning “Non-constant range: argument must be an integer literal”

Which is true, if I swap it for the number ‘4’ it stops complaining. I guess in the initialiser for ForEach there’s something specifying this although it’s not clear to me why. Again it’s an initialiser mystery because I can make the warning go away by adding the id reference to self.

Googling for the warning finds a page on the Hacking with Swift forums that throws a little bit of light on the issue by looking at the inits.

The difference between these two that we’re interested in is that in the first, the type is Range, and the second Data. @RoosterBoy’s explanation for why we should use literal ints for the range is that it’s to be safe from the array changing size during the loop - which is slightly unsatisfying because that could still happen with the literal int range.

Grumble One again

These initialisers also shed some light on my first problem, the references used by SwiftUI should be KeyPaths. Sarun’s explanation of them makes them sound like actual references - ie memory addresses for the properties. That would make sense since SwiftUi wants them to keep track of things.

So I tried this:

ForEach(agents, id: \String.$0) {
 Text($0)
}

but the compiler is still unhappy - so clearly I am not knowledgeable enough yet to solve this one.

Int.times()

Sat, 27 Aug 2022 00:00:00 +0000

When writing yesterday’s post about iterating through a range or collection and using the underscore to throw away the item, I had in the back of my mind that there should be a more straightforward way of doing something a number of times.

Just to re-iterate (lol), here’s the issue. If we want to print “Here’s the thing” three times, in Swift the simplest we can do is:

for _ in 1…3 { print(“Here’s the thing”) }

I had the idea, that this should really be a method of the Int type. And in fact I could write it as an extension that took a closure. Then we could just do this:

3.times { print(“Here’s the thing”) }

That feels much more like the Swift way of doing things (although I probably picked it up during a brief flirtation with Ruby). Of course, I’d implement it with a while loop and a counter, so there’d still be the counter memory allocated, but only for an Int rather than the Array element type.

With this system, the problem I was talking about yesterday:

let thingStrings = [“Thing one”, “Thing two”, “Thing three”]

for _ in thingStrings { print(“Here’s the thing”) }

would become:

let thingStrings = [“Thing one”, “Thing two”, “Thing three”]

thingStrings.count.times { print(“Here’s the thing”) }

Which is, I admit, not amazingly better, but better, especially if the compiler is allocating the memory and filling it with each array value in the first example (which I don’t know if it is, but am increasingly interested in finding out).

Feeling pretty pleased with myself for inventing this new Int method, I had a extra thought that in fact, the Swift community may already of invented this and incorporated it in the language, so I should google it first. It turns out it’s not aprt of the official language, but neither (unsurprisingly) am I the first to think of it.

There’s a Stack Overflow answer to a question “What is the shortest way to run same code n times in Swift?”

So shout out to Matteo Piombo for doing the work for my idea seven years before I had it! It’s still just for code clarity, but great use of extensions and closures.

I still maintain that for _ in is not great, and that for each in where each was a synonym for the underscore would be the prettiest solution. A likely con of this proposal is that is would be a code breaking change for any code that has already uses for each which could be quite common.

The _ Underscore

Fri, 26 Aug 2022 00:00:00 +0000

I’ve learned (so far) an underscore can be used for a couple of things in Swift, both of them loosely translating to “doesn’t really matter”.

The first is in a parameter name for a function. Swift has a very cool feature I haven’t seen before where an argument can have a different internal and external name. As usual, this will make more sense in code. Imagine this:

func sumNumbers(firstNumber: Int, secondNumber: Int) -> Int { return firstNumber + secondNumber }

let sum = sumNumbers(firstNumber: 5, secondNumber: 3 )

Using the magic of internal and external parameter names, we can make the function call read a bit better. The external parameter name goes first and is separated from the internal name by a space.

func sumNumbers(numbers firstNumber: Int, and secondNumber: Int) -> Int { return firstNumber + secondNumber }

let sum = sumNumbers(numbers: 5, and: 3 )

That makes the function call a little clearer, but we can go one better by making the external name of the first parameter optional using the underscore:

func sumNumbers(_ firstNumber: Int, and secondNumber: Int) -> Int { return firstNumber + secondNumber }

let sum = sumNumbers(5, and: 3 )

So that’s the first use - to make a parameter of a function unnamed in the call.

The second is in loops where we don’t care about the item we’re extracting. Normally we want to do something with each item in a collection we’re iterating through. For example, we might want to print each string in an array:

let thingStrings = [“Thing one”, “Thing two”, “Thing three”]

for thing in thingStrings { print(thing) }

But what if we didn’t? Perhaps this is what we’re doing:

let thingStrings = [“Thing one”, “Thing two”, “Thing three”]

for thing in thingStrings { print(“Here’s the thing”) }

We’ve sort of created a variable for no purpose - it’s not referenced. If that’s our intention, it would be better to have the compiler know that so if we inadvertently use it, it would warn us. The underscore comes to help with this, we can just:

let thingStrings = [“Thing one”, “Thing two”, “Thing three”]

for _ in thingStrings { print(“Here’s the thing”) }

I have no idea if this results in better binary code - ie if LVM was reserving memory for thing in the previous example. Knowing Chris Lattner, it probably is smarter than that.

Although one quickly gets used to reading code like the above example, I don’t really like this use of the underscore. The code does not read well, it’s not Swifty enough. I’d probably say:

let thingStrings = [“Thing one”, “Thing two”, “Thing three”]

for eachThing in thingStrings { print(“Here’s the thing”) }

Thinking about this today whilst driving back from shopping, I hit on the idea there should be a reserved word “each” to achieve the same purpose as the underscore, but perhaps the code above is as good as we can get. It will do until I find out if LVM is optimising it away. (Paul says, obliquely, it is not)

I’m not forgetting about the .forEach method on arrays. But that has the same issue - it forces me to name (or underscore) the variable to hold the value we’re iterating past.

let thingStrings = [“Thing one”, “Thing two”, “Thing three”]

thingStrings.forEach { _ in print(“Here’s the thing”) }

Codewars / reduce

Wed, 24 Aug 2022 00:00:00 +0000

codewars.com is a “coding practice” website. You chose a language and a skill level, then it offers up a task (or kata) for you to write a suitable function. The first one it gave me was seemed too hard, so I changed my level to beginner and skipped to the next one. This was my task:

 Given an array of integers, find the one that appears an odd number of times.
 
 There will always be only one integer that appears an odd number of times.
 
 Examples
 [7] should return 7, because it occurs 1 time (which is odd).
 [0] should return 0, because it occurs 1 time (which is odd).
 [1,1,2] should return 2, because it occurs 1 time (which is odd).
 [0,1,0,1,0] should return 0, because it occurs 3 times (which is odd).
 [1,2,2,3,3,3,4,3,3,3,2,2,1] should return 4, because it appears 1 time (which is odd).

I know there’s a cool “Set” container type in Swift, so my plan was to iterate through the array, then for each number if there’s no entry in the set, then add one, but if there is, remove it. That way whatever is left in the set at the end must be in the original array an odd number of times. I was pretty pleased with myself. Here’s the code I Playground’d up:

func oddTimesInt(intArray: [Int]) -> Int {

var intSet: Set<Int> = \[\]

for number in intArray {
 if intSet.contains(number) {
 intSet.remove(number)
 } else {
 intSet.insert(number)
 }
}

assert(intSet.count == 1)
if let firstNumber = intSet.first {
 return firstNumber
} else {
 // this is guaranteed not to happen in the specification
 assert(false)
 return 0
}

}

While you are writing your code in their webpage, you can run it against a test suite. Mine passed the first time; even more pleased with myself.

When you’re ready, you can submit your code. Now it runs against a much bigger test suite. It passed again; now my head is swelling a little at just how canny I am.

There’s a chance to clean up, comment, or to refactor your code before it’s finally locked in. Then once you commit that, it shows you other people’s solutions. This was the top one:

func findIt(_ seq: [Int]) -> Int { seq.reduce(0, ^) }

lol. One. Line. That’ll learn me.

So, anyways…. I guess I learned there’s an array method called reduce, and it reduces an array, but I want to argue my code is easier to understand.

According to the docs, reduce “Returns the result of combining the elements of the sequence using the given closure.” Basically, the 0 in the example above is the inital value of the accumulator, then the closure repeatedly operates on the accumulaotr and each value of the array, then the final result in the accumulator is returned. An example will make a lot more sense. Here’s the one from the Apple documentation:

let numbers = [1, 2, 3, 4] let numberSum = numbers.reduce(0, { x, y in x + y }) // numberSum == 10

The closure in the winning entry used all the closure redaction tricks I think I’ve complained about before. We could make it a bit more readable by putting syntax back.

func findIt(_ seq: [Int]) -> Int { seq.reduce(0, {accumulator, element in accumulator ^ element} ) }

or to go back another step:

func superXOR(accumulator: Int, element:Int) -> Int { return accumulator ^ element }

func findIt(_ seq: [Int]) -> Int { seq.reduce(0, superXOR ) }

The ^ operator is XOR. I know what that does, and could even manually do it on two binary numbers.

This compact solution is based on knowing that XORing all the integers will leave the odd value, since XORing two identical numbers gives zero, and that carrying forward the XORed value of two different numbers will shake out to leave the number that only appears once. I was not going to think of that solution, even if I’d known reduce() existed.

Named Loops

Sun, 21 Aug 2022 00:00:00 +0000

Here’s a neat thing I haven’t seen before. Other languages I’ve worked in haven’t had a neat way to break out of a set of nested loops to a particular loop. It’s not an issue that comes up a lot, but when it has I’ve solved it by creating a continue flag and having that as the first condition of each loop.

To explain, say if we had these two loops (in C):

int i; int j; char string[] = “This string”; int length = strlen(string);

for (i=0; i<=3; i++) {

for (j=0; j<length; j++) {
 printf("char:%c num:%d\\n", string\[j\], i);
}

}

and for some unexplained reason, we need to break out of both loops when we encounter a lowercase ‘t’. There is a C command to break out of a loop - break. But it only breaks out of the current loop:

int i; int j; char string[] = “This string”; int length = strlen(string);

for (i=0; i<=3; i++) {

for (j=0; j<length; j++) {
 printf("char:%c num:%d\\n", string\[j\], i);
 if (string\[j\] == 't') {
 break;
 } 
}

}

Since the outside loop that is iterating ‘i’ is not broken out of, we still end up looping through to the letter ‘t’ four times. Like this:

char:T num:0
char:h num:0
char:i num:0
char:s num:0
char: num:0
char:s num:0
char:t num:0
char:T num:1
char:h num:1
char:i num:1
char:s num:1
char: num:1
char:s num:1
char:t num:1
char:T num:2
char:h num:2
char:i num:2
char:s num:2
char: num:2
char:s num:2
char:t num:2
char:T num:3
char:h num:3
char:i num:3
char:s num:3
char: num:3
char:s num:3
char:t num:3

So in C/C++ I would convert the loops to while, and set a continue flag. First the whiles:

int i; int j; char string[] = “This string”; int length = strlen(string);

i = 0; while (i <=3) {

j=0;
while (j<length) {
 printf("char:%c num:%d\\n", string\[j\], i);
 if (string\[j\] == 't') {
 break;
 } 
 j++;
}

i++;

}

Then the flag, which I’ve called keepGoing:

int i; int j; char string[] = “This string”; int length = strlen(string) ;

int keepGoing = true; i=0; while (keepGoing==true && i <=3) {

j=0;
while (keepGoing==true && j<length) {
 printf("char: %c num: %d\\n", string\[j\], i);
 if (string\[j\]=='t') {
 keepGoing = false;
 }
 j++
}

}

This gives us the output we want and we can close the ticket. Note that I have
typedef’d true and false off-screen in the code above.

char:T num: 0
char:h num: 0
char:i num: 0
char:s num: 0
char: num: 0
char:s num: 0
char:t num: 0

With Swift, we can just name the loops, then break out to a named loop level:

littleLoop: for i in 0…3 { bigLoop: for char in “This string” { print(“char:\(char) num:\(i)”) if char==“t”{ break littleLoop } } }

Note that I didn’t need to name the internal littleLoop, that was just showing off.

Protocols

Tue, 16 Aug 2022 00:00:00 +0000

The evolution of structs into class-like things that can hold properties and methods in Swift raised in my mind “what about inheritance?” - but no: structs in Swift can not use inheritance.

Swift classes implement inheritance, but only from one class; there’s no multiple inheritance. Protocols neatly address both these concerns to a large extent, but perhaps before we look at how they work, we should have a brief diversion into inheritance in C++.

#include

class Shape { public: int sides; };

class Drawable { public: virtual void draw() {} };

class Square : public Shape, public Drawable { public: Square(){ sides = 4; }

 void draw() {
 std::cout << "■" << std::endl;
 }

};

int main() { Square square; square.draw(); return 0; }

In the code above, there’s two classes Shape and Drawable. You could regard Drawable as an interface if you’re coming from Java world (because the method draw() is marked virtual - there’s no implementation). The class Square inherits from both those classes - it’s a new class that is a Shape, but is also Drawable. (Line 15 above)

Perhaps in this program there’s other items such as images or text - ie not shapes which might also inherit from Drawable. Elsewhere, we could have a method that had to draw a collection of things - it doesn’t care what the items are, as long as they are Drawable - they have to implement the Draw() method.

Swift addresses most of these needs with Protocols. A protocol defines a set of properties and methods. Then a struct, class, or even enum can conform with this protocol - they contain the same properties, and are required by the compiler to implement the methods from the protocol.

Here’s the Swift equivalent of the C++ above:

protocol Shape { var sides: Int { get set } }

protocol Drawable { func draw() }

struct Square: Shape, Drawable { var sides: Int = 4 func draw() { print("■") } }

let square = Square() square.draw()

So, that’s cool, but not amazing. The power is really that now we can write a function that takes anything that’s Drawable as if it was a real type. To wit:

class IanClass: Drawable { func draw() { print(“Ian”) } }

func drawAThing(_ thingToDraw: Drawable){ thingToDraw.draw() }

let squareStruct = Square() let ianClass = IanClass()

drawAThing(squareStruct) drawAThing(ianClass)

So the function drawAThing() is happy to draw anything, as long as it conforms with the Drawable protocol by implementing the draw() method. It doesn’t even matter what it is - as in this example where we’ve passed it a struct on one occasion, and a class on another.

Protocols are a great example of Swift being flexible while being type-safe.

Rust

Fri, 12 Aug 2022 00:00:00 +0000

It’s been exciting to see some of the modern language features in Swift - it’s a real joy to work in when I think back to my C++ days which was some of the last commercial programming I did.

The buzz about Carbon got me wondering about other new languages and what might be going on with them. Rust seems to keep popping up in conversations so I thought I’d have a quick look.

Also read A half-hour to learn Rust and A Swift Guide to Rust

Those optionals, type inference, type safety, and exhaustive switch/match statements sure look familiar. Ranges too, and although the infinite range looks cool I’m not sure of the use-case.

Blocks evaluating to a result is cute. This is allowed:

let x = { let y = 1; // first statement let z = 2; // second statement y + z // this is the *tail* - what the whole block will evaluate to };

Notice the missing semicolon - that’s sugar for the ‘return’ that would be otherwise needed. Perhaps only from habit, I do miss the semicolons when writing Swift. I’m sure I’ll get used to it, but currently I start to feel uncomfortable when spreading an expression out over multiple lines (for clarity) and just expecting LVM to figure it all out.

 Button("Toggle Light", action: {
 light.toggle()}
 )
 .padding()
 .font(.title)
 .foregroundColor(.white)
 .background(Color.accentColor)
 .cornerRadius(10)
 .padding()
 Spacer()

Underscore as a “throwaway” value turns up, but in the guise of default for the match statement.

Variable bindings, by default (with ’let’) are immutable in Rust, but can be marked as ’let mut’ to make them fully variable, as with Swift’s ‘var’.

Rust has “traits”, which currently my knowledge of Swift can’t do justice to a compare and contrast, but it definitely has a superclassy feel - like protocols and extensions.

They both have closures, but again, I’m getting out of my current depth on Swift to make any worthwhile comment.

I do enjoy about Swift how clear it is to read, from what I’ve seen of Rust, that’s not so much the case there, I guess there’s some other trade off involved.

Chris Lattner

Wed, 03 Aug 2022 00:00:00 +0000

Thank you YouTube algorithm for this recommendation - Chris Lattner, the main author of Swift (amongst other things including LVM) chatting with Lex Fridman. Ignore the clickbait title. There is a good, brief discussion about the tradeoffs in value vs references types which is a topic I’ve been thinking a bit about this week.

Also some interesting comments about how a language delivers it’s complexity. Chris gives the funny example of what “hello world” looks like in Swift vs C++. Here’s Swift: Print("Hello world"), here’s C++:

#include <iostream>

int main() {
 std::cout << "Hello World!";
 return 0;
}

Especially when part of my interest is in exciting kids in programming, that’s a stark difference. Swift does go on to do the hard things - it’s used for native apps and has some of the great modern language features, but the simple things are easy. I am very happy with the idea of Swift (especially plus Playgrounds) being a smooth introduction to coding. Less so with SwiftUI - that gets complicated quickly when things go wrong.

Retain Cycle

Tue, 02 Aug 2022 00:00:00 +0000

Variables and constants in Swift can be a value type (their data is copied when they are copied) or a reference type (a pointer to the data is passed when they are copied.

Structs, integers, and enums are value types, classes are reference types.

Memory management of value types is relatively straightforward - there’s a 1:1 relationship between the variable name and its data, so if the variable goes out of scope it can get the chop. With reference types, it’s possible to have several variables (or class or struct properties etc) all pointing to the data, so a more sophisticated system is needed to know when it’s safe to delete the data.

In Swift (and some other languages), this memory management is done by Automatic Reference Counting ARC. The compiler inserts code that keeps track of what references exist in scope that point to the data in memory that could potentially be freed. When there are zero references exisiting for an object, it can be freed. Here’s an example, meet SomeClass:

class SomeClass{
 var name: String = ""
 var otherClass: SomeClass?
 
 init(name: String){
 self.name = name
 otherClass = nil
 print("init")
 }
 deinit{print("deinit")}
}

This class has a couple of properties; a name and a link to another object of the same class. The init and deinit methods are called at creation and destruction. I’ve added print() so we can see them.

func classCreationFunction(){
 print("start")
 var class1 = SomeClass(name: "class1")
 var class2 = SomeClass(name: "class2")
 class1.otherClass = class2
 print("end")
}

If we run this function, the output will be:

start
init
init
end
deinit
deinit

Two instances created, two released. All this is done for us (the Automatic in ARC), when I was programming in Delphi, it was often the responsibility of the programmer to explicitly deal with this problem.

A potential problem with ARC is retain cycles. A retain cycle is where objects (or often a chain of objects) hold references to each other. We’re done with the objects, but because they are holding the references to each other, the references have not been counted down to zero, and therefore ARC does not kill them off. In classCreationFunction above, one instance has a reference to another, and ARC cleans them both up.

What happens if we have each instance hold a reference to each other? Something like this:

func classCreationFunction(){
 print("start")
 var class1 = SomeClass(name: "class1")
 var class2 = SomeClass(name: "class2")
 class1.otherClass = class2
 class2.otherClass = class1
 print("end")
}

The output of this is:

start
init
init
end

Two instances of SomeClass created, none destroyed.

Bump One

Mon, 01 Aug 2022 00:00:00 +0000

Most of the things I’ve learned so far have been familiar, interesting, or cool - but now I’ve ventured far enough into the Swift Language Programming book to find something that is definitely going to take a couple of readings to piece together.

I was surprised, then pleased with functions as first class types, and the idea of passing closures around is powerful and useful.

My current difficulty is getting my head around closures capturing variables. It was tolerable (but not safe) when I just thought of it as a pointer, but when turned out the captured variable continues to exist in some sort of zombie state even after the scope where the variable was contained has ended.

To go back a bit, nested functions have access to the variables declared in the scope they are nested in.

func someFunction(){
 var someInt = 4
 nestedFunction()
 print(someInt)
 
 func nestedFunction(){
 someInt += 1
 }
}

I don’t approve of this. It has a global variable flavour. For most purposes I’d rather pass and return the values so the intent is all contained. Nevertheless, I can see it’s a valid approach that might be useful.

I can’t explain the next bit any better than the Swift book, so here’s it’s opening on Capturing Values:

Here’s my slight edit to the code from the book to get it to print out the incrementing values. This prints ”10” and ”20” to the console.

func makeIncrementer(forIncrement amount: Int) -> () -> Int {
 var runningTotal = 0
 func incrementer() -> Int {
 runningTotal += amount
 return runningTotal
 }
 return incrementer
}

let incrementByTen = makeIncrementer(forIncrement: 10)
print(incrementByTen())
print(incrementByTen())

So, makeIncrementer returns its nested incrementing function which has “captured” the runningTotal variable. The scope that runningTotal lives in has gone (when makeIncrementer finished) but runningTotal is still alive. I assume that this deep magic is made possible by our friend Automatic Reference Counting. This variable capture in closures seems like a weapon that needs wielded with great care.

Closures

Mon, 25 Jul 2022 00:00:00 +0000

I had one of those synchronicity in learning moments this morning. I am reading The Swift Book - ie The Swift Programming Language, Swift 5.7 as part of my cs193p homework, and this morning, in a coffee shop was admiring what a clear, well written explanation was given for closures. It is super well written, stepping the reader through in logical (and digestible) steps.

If you’ve never carelessly passed around a pointer to a function and caused the Blue Screen of Death, or done much multi-threaded programming, the use-case for closures, and use of them is going to be challenging at first. Then Swift’s ability to cut the syntax down to very little will be challenging.

By pure coincidence, on the way home (it’s the country - you have time to listen to most of a podcast on the drive home from town) I listened to Fireside Swift podcast episode 7 which was also about closures.

The to top it off, I sat down to lunch with this video which is part of iOS Academy’s Swift for Beginners (2022) playlist.

struct

Mon, 18 Jul 2022 00:00:00 +0000

Started on Day 10 of 100 days of etc etc today which is about structs. It was immediately clear when I first started looking at Swift and Swift UI that structs were going to be a big deal. I am used to structs being able to contain a collection of other types, but not methods. So I was confused at why tuples existed; that is now cleared up.

If structs can have methods as well as properties, it answers the question of why tuples exist, but immediately asks the question, why have classes since structs have all this power? I already know (from my podcast consumption) one of the answers for this is that structs are value types rather than references. When you:

let someConstant = someClass

someConstant now contains a copy of the pointer to someClass, as opposed to making a copy as similar code would do for a struct. So this code:

struct SomeStruct {
 var counter: Int = 0
}

var structInstance = SomeStruct()
var someOtherStruct = structInstance

print("structInstance:\(structInstance.counter)")
print("someOtherStruct:\(someOtherStruct.counter)")

someOtherStruct.counter += 1

print("structInstance:\(structInstance.counter)")
print("someOtherStruct:\(someOtherStruct.counter)")

print("")

class SomeClass {
 var counter: Int = 0
}

var classInstance = SomeClass()
var someOtherClass = classInstance

print("classInstance:\(classInstance.counter)")
print("someOtherClass:\(someOtherClass.counter)")

someOtherClass.counter += 1

print("classInstance:\(classInstance.counter)")
print("someOtherClass:\(someOtherClass.counter)")

Produces the output:

structInstance:0
someOtherStruct:0
structInstance:0
someOtherStruct:1

classInstance:0
someOtherClass:0
classInstance:1
someOtherClass:1

The sample code for the Hello World app in playgrounds ONLY contains structs. The app is a struct, containing a view which is a struct. That’s basically all there is, so clearly structs are going to be a big deal.

Tuple Pronunciation

Tue, 12 Jul 2022 00:00:00 +0000

Another advantage of the videos, that hadn’t occurred to me when I mentioned it the other day, is learning the correct pronunciation of things you’ve only ever read in books.

Apparently, tuple is pronounced two-pull, and not with the tup to rhyme with cup as I’d always imagined. Google has confirmed, so it’s not just a UK thing.