I naïvely thought that one post a month was a nice target to aim for this year, and here we are in February.
Last year I started learning Swift, and I'm going to ramble on about it. As background, I'm a software developer. Most of my work is in C++, C#, and a bit of JavaScript. I've also written a lot of D. So mostly 'brace languages', so Swift isn't too far out of my comfort zone.
I try and learn new languages and technologies to avoid getting stuck in a technology stack local maximum. Perhaps "system languages" is an outdated term, so I'll say that I'm generally the most interested in languages that compile to native code.
There's been a lot of talk in the news about memory safety. So while I am one of those strange people that enjoy working in C++, it seems that knowing some modern alternatives would be valuable. (I have complex feelings about memory safety -- probably worthy of its own post.)
Why Swift? Why not Rust, Zig, or Odin? The main reason initially was that I recently switched my main phone to an iPhone, and have started using macOS more. Learning Apple's Objective-C replacement seemed like a good idea.
This isn't intended to be a comprehensive overview, or a review. Just my thoughts. For context, I've written a level editor for a game project using SwiftUI, and a GameBoy emulator using Raylib, among other smaller projects.
One thing that appealed to me has nothing to do with the language itself. The Swift project has official forums. It seems that a lot of technology communities get siloed off into Discord and Slack channels, which act as information black holes - trapping shared knowledge beyond their event horizons. Community is often ignored when we speak of new languages, but it's actually a large part of the experience of using these tools.
If we're to talk about syntax, we'll need an example. Here's a function from the afore mentioned GameBoy emulator, chosen arbitrarily.
/// OR the given register against the A register, storing the result in the A register.
mutating func or(regAWith target: Target) -> ExResult {
assert(target.isR8 || target.isN8 || target == .refR16(.hl))
let value = if case .r8(let r8) = target {
read(from: r8)
} else if case .n8(let n8) = target {
n8
} else {
bus.readByte(at: registers.hl)
}
registers.a = registers.a | value
registers.f.rawValue = 0
registers.f.zero = registers.a == 0
if case .r8 = target {
return (cycles: 1, registers.pc &+ 1)
} else if case .refR16 = target {
return (cycles: 2, registers.pc &+ 1)
} else {
assert(target.isN8)
return (cycles: 2, registers.pc &+ 2)
}
}
The syntax is very clean. It should be fairly familiar to anyone who has worked in an Algol descended language. It omits a lot of the ceremony present in other languages -- semicolons, parens, type names are all omitted at times.
The eagle-eyed reader will have noticed that Swift has the labelled arguments of Objective-C:
read(from: r8)
This took a little getting used to, but I've come to like it. Good labels can really clarify the call site for casual code reading.
Binding to C and C++ libraries is fairly easy. The incantations required to get SwiftPM working for such code is a little obscure (I found much more success in looking at existing projects than trying to find the correct documentation.) I've mostly been working with C libraries, but the prospect of working directly with C++ code without having to write a C shim is very exciting for gradual adoption.
The sheer volume of 'magic' syntax can make learning Swift if you have experience in other older brace languages a little jarring. Here's a View from my level editor as a demonstration:
struct LevelView: View {
@ObservedObject var document: RiftAceEditorDocument
@EnvironmentObject var selectedTriggers: SelectedTriggers
@State var offset = CGSize.zero
var body: some View {
ZStack {
Image(nsImage: document.backgroundImage)
.onTapGesture {
selectedTriggers.removeAll()
}
ForEach($document.level.triggers) { trigger in
TriggerView(trigger: trigger.wrappedValue, imageHeight: $document.backgroundImage.size.height)
}
}
}
}
I want to focus in on the body property. Every View in SwiftUI will have this. When I first encountered these I had a lot of questions. What is some View, versus just a plain View? What is ZStack { ... } doing there? Is it a function call? A type declaration? How can it have an if statement?
I won't answer all of those questions, but the SomeType { is usually the result of that lack of ceremony I mentioned. If the last parameter to a function is a closure (function object) the parens can be omitted. Most of the rest are a result of body being a view builder. People tend to have a love-or-hate reaction to result builders. I've not decided where I fall on them.
One thing that came up while I've been writing that emulator are Swift's enums. Coming from C++, getting enums with associated values and pattern matching is a big upgrade -- I'm a fan. However, there is one small wart:
enum ByteTarget {
case a
case b
}
enum Target {
case r8(ByteTarget)
case r16
}
In an if statement, if I want to detect a Target and I don't care about the associated value, I can do this:
if case .r8 = value {
print("value is an r8")
}
That might make you think that case is an expression. It isn't -- if case is its own thing. You can't do this:
if case .r8 = value || case .r16 = value {
print("value is an r8 or an r16")
}
Nor this:
assert(case .r8 = value)
The workaround is to created computed Bool properties. Not the end of the world, but it is annoying.
If you write large expressions you may see a frankly embarrassing error message:
The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
Similarly, large array literals can cause compilation times to explode. As I understand it, this is a result of the type checker. This can lead to the Swift compiler dying on expressions and literals that look fairly simple to the human behind the keyboard.
Overall, I'm fairly positive on Swift. I'm still fairly new to it, and I don't understand everything (still trying to get my head around the Swift 6 concurrency stuff). I expect I'll be writing more of it and getting more familiar.