With the introduction of Codable in Swift 4, working with JSON has never been more pleasant. Until it’s not. Codable definitely has its warts, and often the pain is introduced by suffering through boilerplate of implementing custom Decodable initializers.

Fortunately, Swift 5.1 introduced a feature known as property wrappers that can take all of that boilerplate away. While it doesn’t magically solve every painpoint with Codable, it definitely makes working with it much more pleasant. To that end, I’ve been accumulating my own wrappers on my GitHub at github.com/marksands/BetterCodable. Keep reading for a deep dive into their implementation and what it has to offer.

Phantom types have been written and talked about enough, so I don’t personally have much to add to the conversation. Instead, I decided to try my luck with Phantom Types to see how well it fits in with my programming style and how ergonomic it feels in “real” code.

This post is a followup to An Exhaustive Look At Memory Management in Swift.

I have been asked when it is appropriate to use unowned versus weak and I think the answer is a little more complicated than providing best practice scenarios. In fact, this currently seems to be a hot debate in the Swift community.

I’ll provide several examples that demonstrate where unowned can be used and when it crashes when you least expect it. My goal is for the reader to gain a better understanding of the tradeoffs of using unowned and hopefully come away with a more informed opinion.

A Glossary of Terms

ARC

ARC, or Automatic Reference Counting, is the compiler provided solution to Manual Retain-Release. MRR required the developer to manually insert retain and release functions to track uses of references, which one can imagine is a recipe for disaster. This concoction made it easy to introduce memory leaks, led to error prone code, and added tedious boilerplate. And so along came ARC, because after all, Apple has to take steps to avoid Copland 2010.

The original Transitioning to ARC Release Notes dive into more detail about how ARC works, but this post will primarily focus on Swift, especially when it comes to dealing with memory in closures.

I work a lot with legacy code and frequently encounter strange and bizarre solutions to otherwise simple problems. Most of the legacy projects I work with share common architectural problems and a set of regular occurring bugs. While I don’t have an answer as to why these common patterns emerge from legacy projects, I will do my best to pull apart some of these issues and write about my findings.

Today I encountered a function that looks more or less like this:

struct Name {
    let firstName: String?
    let middleInitial: String?
    let lastName: String?
}

func fullName(name: Name) -> String {
    var fullName = ""
    if let firstName = name.firstName {
        fullName += firstName.trimmingCharacters(in: .whitespacesAndNewlines)
    }
    if let middleInitial = name.middleInitial {
        fullName += " " + middleInitial.trimmingCharacters(in: .whitespacesAndNewlines)
    }
    if let lastName = name.lastName {
        fullName += " " + lastName.trimmingCharacters(in: .whitespacesAndNewlines)
    }
    return fullName
}

Notice any bugs? What does fullName return when the firstName or the middleInitial is nil?