Figure

What to Do with Localized Errors

Sun, 08 Aug 2021 01:00:00 -0500

Last week we found the easiest way to retrieve localized context from an error. This gives us three values to play with:

Description
Failure Reason
Recovery Suggestion

But how do we use these to effectively communicate an error to our users?

To figure it out, we should start by looking at the invariant — the one thing out of our power to control; the values native frameworks give to their errors. Here’s a small list:

Apple Framework Examples

Network Connection without Entitlement:

Description: ‘The operation couldn’t be completed. Operation not permitted’
Reason: ‘Operation not permitted’
Recovery: N/A

Network Timeout:

Description: ‘The request timed out.’
Reason:N/A
Recovery:N/A

Network is Offline:

Description: ‘The Internet connection appears to be offline.’
Reason:N/A
Recovery:N/A

File Not Found:

Description: ‘The file “hello” couldn’t be opened because there is no such file.’
Reason: ‘The file doesn’t exist.’
Recovery:N/A

Bad File URL:

Description: ‘The file couldn’t be opened because URL type http isn’t supported.’
Reason: ‘The specified URL type isn’t supported.’
Recovery:N/A

File exists:

Description: ‘“hello” couldn’t be copied to “Users” because an item with the same name already exists.’
Reason: ‘A file with the name “hello” already exists.’
Recovery: ‘To save the file, either provide a different name, or move aside or delete the existing file, and try again.’

Localized Lessons

The first thing we learn is that these values are not supported equally across Apple’s libraries. While there’s always a description present, the recovery suggestion in particular is rarely used.

But we do see a pattern. Generally, the failure reason (when present) provides a short and conscience explanation of the error. Quick and to the point.

The description often restates the failure, but goes more in-depth. It might identify the particular error or some of the values involved, for example.

Finally, if the error is specific enough that a workaround can be assumed by the library author, that is written up and given in the recovery suggestion.

Hi, Alert

These usages suggest an easy mapping with the standard Alert dialog.

First we cast the incoming error as an NSError. Then we derive a title from its failure reason (or substitute a default title in case there’s no reason specified):

let bridge = myError as NSError

let title = 
  bridge.localizedFailureReason 
  ?? "An Error Occurred"

Then we take the description and the recovery suggestion (if it exists) and create a message body by joining them together with a space between:

let message = [
  bridge.localizedDescription,
  bridge.localizedRecoverySuggestion,
]
.compactMap { $0 }
.joined(separator: "\n\n")

Note that we don’t need to give a default here. The localized description of an NSError will never be empty. And if there’s no recovery suggestion, we just don’t add it.

Once we have a our title and message, we can pass them along to our alert controller:

let alert = UIAlertController(
  title: title, 
  message: message, 
  preferredStyle: .alert
)

When we present it, it’ll look something like:

Breaking with Tradition

To some long-time Cocoa developers, this may look a little strange. After all, AppKit provides a presentError(_:) method on NSWindow that uses the description as the title and only renders a message if there’s a recovery suggestion given:

Why not adopt this style ourselves? We’ll talk about this more next week when we dissect how to write a good error.

Practical Localized Error Values in Swift

Sun, 18 Jul 2021 01:00:00 -0500

How many times have we stared at code like:

do {
  try writeEverythingToDisk()
} catch let error {
  // ???
}

or even:

switch result {
case .failure(let error):
  // ???
}

and asked ourselves “How am I going to communicate that error?”

The thing is, that error likely contains a lot of information that could help us out. But getting to it is not always straight forward.

To see why, let’s look at the techniques at our disposal for attaching information to errors.

The New: `LocalizedError`

In Swift we pass around errors that conform to the Error protocol. The LocalizedError protocol inherits from this and extends it with some useful properties:

errorDescription
failureReason
recoverySuggestion

By conforming to LocalizedError instead of Error (and providing an implementation for these properties), we can stuff our error with a bunch of useful information that can be communicated at runtime (NSHipster goes way more in-depth on this):

enum MyError: LocalizedError {
  case badReference

  var errorDescription: String? {
    switch self {
    case .badReference:
      return "The reference was bad."
    }
  }
    
  var failureReason: String? {
    switch self {
    case .badReference:
      return "Bad Reference"
    }
  }

  var recoverySuggestion: String? {
    switch self {
    case .badReference:
      return "Try using a good one."
    }
  }
}

The Old: `userInfo`

Good old NSError provides a userInfo dictionary that we can fill with anything we want. But it also provides some predefined keys:

NSLocalizedDescriptionKey
NSLocalizedFailureReasonErrorKey
NSLocalizedRecoverySuggestionErrorKey

We might note these are very similar in name to the properties LocalizedError provides. And, in fact, they perform a similar role:

let info = [ 
  NSLocalizedDescriptionKey:
    "The reference was bad.",
  NSLocalizedFailureReasonErrorKey:
    "Bad Reference",
  NSLocalizedRecoverySuggestionErrorKey:
    "Try using a good one."
]

let badReferenceNSError = NSError(
  domain: "ReferenceDomain", 
  code: 42, 
  userInfo: info
)

So seems like LocalizedError and NSError ought to be mostly interchangeable then, right? Well, therein lies the rub.

The Old Meets the New

See, NSError implements Error, but not LocalizedError. Which is to say:

badReferenceNSError is NSError        //> true
badReferenceNSError is Error          //> true
badReferenceNSError is LocalizedError //> false

This means if we try to get data out of some unknown error in the obvious way, it works as expected for Error and LocalizedError, but only reports a localizedDescription for NSError:

// The obvious way that doesn’t work:
func log(error: Error) {
  print(error.localizedDescription)
  if let localized = error as? LocalizedError {
    print(localized.failureReason)
    print(localized.recoverySuggestion)
  }
}

log(error: MyError.badReference)
//> The reference was bad.
//> Bad Reference
//> Try using a good one.

log(error: badReferenceNSError)
//> The reference was bad.

That’s pretty annoying because we know our NSError has a failure reason and recovery suggestion defined in its userInfo. It’s just, for whatever reason, not exposed via LocalizedError conformance.

The New Becomes the Old

At this point we may despair, picturing long switch statements trying to sort types and test existence of various userInfo properties. But never fear! There is an easy solution. It’s just non-obvious.

See, NSError has convenience methods defined on it for extracting localized description, failure reason, and recovery suggestion from the userInfo:

badReferenceNSError.localizedDescription
//> "The reference was bad."

badReferenceNSError.localizedFailureReason
//> "Bad Reference"

badReferenceNSError.localizedRecoverySuggestion
//> "Try using a good one."

Which is great for handling an NSError, but doesn’t help us get these values out of a Swift LocalizedError… or does it?

It turns out Swift’s Error is bridged by the compiler to NSError. Which means we can treat an Error as an NSError with a simple cast:

let bridgedError: NSError
bridgedError = MyError.badReference as NSError

More impressively, though, when we cast a LocalizedError in this way, the bridge does the right thing and wires up localizedDescription, localizedFailureReason, and localizedRecoverySuggestion to point to the appropriate values!

So if we want a consistent interface to pull localized information out of Error, LocalizedError, and NSError, we just need to blindly cast everything to an NSError first:

func log(error: Error) {
  let bridge = error as NSError
  print(bridge.localizedDescription)
  print(bridge.localizedFailureReason)
  print(bridge.localizedRecoverySuggestion)
}

log(error: MyError.badReference)
//> The reference was bad.
//> Bad Reference
//> Try using a good one.

log(error: badReferenceNSError)
//> The reference was bad.
//> Bad Reference
//> Try using a good one.

Once we have all this delicious context about our errors, what should we do with it? That’s the topic of next week’s post. See you then!

Cleaning up Async Without Swift 5.5

Mon, 14 Jun 2021 01:00:00 -0500

It’s finally here! After seven years of callbacks and completion handlers, we now have a way to cleanly and correctly make asynchronous calls in Swift without endless nesting. It’s async/await and it’s awesome.

Sadly, these new features require runtime support. Which means, at least for the time being, async is iOS 15-/macOS 12-only.

For those of us supporting older deployment targets, this can be a bit of a let down. But not all hope is lost! We can build clean, flattened-out async handling on our own. And maybe learn a thing or two about the nature of asynchrony along the way?

async/await

Let’s start with a description of the problem and how Swift 5.5 solves it.

Given a series of dependent, asynchronous calls, we currently have to write them in a bunch of nested callbacks:

func fetchPortrait(
  user: UUID, 
  completion: (Image)->Void
) { 
  fetchAvatar(user: user) { url in
    fetchImage(url: url) { image in
      completion(image)
    } 
  }
}

This works, but execution jumps all over the place spatially and temporally making the code hard to reason about and prone to errors. We would like to specify our async calls procedurally, instead. One right after the other, no nesting.

Swift 5.5 solves this with async/await:

func fetchPortrait(user: UUID) async -> Image {
  let url = await fetchAvatar(user: user)
  let image = await fetchImage(url: url)
  return image
}

How are they doing that? Swift.org sheds some illumination:

An asynchronous function … is a special kind of function that can be suspended while it’s partway through execution.

Long time readers will recognize this as a coroutine. A coroutine is ideal for handling asynchronous work because we can suspend it just after it begins its async job, then resume it again right where it left off when the job completes and we’re ready to continue.

Coroutines on the Cheap

This flow of events might sound familiar. Let’s look a little closer look at the execution of a standard “completion handler” function:

func prettyHTML(
  url: URL, 
  completion: (HTML)->Void
) {
  getPage(url: url) { html in
    // Do work to format the HTML...
    completion(html)
  }
}

In this example, prettyHTML starts getting some HTML via getPage… and then returns. Some time later, the closure we passed to getPage is called, and work is done to pretty up the HTML.

In other words, prettyHTML is essentially “suspended while it’s partway through execution.” And then, at some later time, its execution is resumed again from that very spot it left off.

Yup. Completions handlers are the poor man’s coroutine. They just require that we bundle up all the state needed to “resume the coroutine” in a closure. It’s that closure that leads to the nesting and non-linear execution flow.

So we already have the building blocks for decent async handling. What we really need is a better way to manage those completion closures.

CPS Strike

So let’s zoom in on our completion handlers. Imagine the simple function:

func fetchAvatar(user: UUID) -> URL

If we want to make this asynchronous by rewriting it as a “cheap coroutine” with completion handler, what do we need to do? Rather than returning the URL we’ll move it to the argument of a new closure we pass in as a parameter:

func fetchAvatar(user: UUID, complete: (URL)->Void)

There’s a name for rewriting functions this way — it’s called Continuation Passing Style or CPS. And the closure we pass when we do this is called a continuation. Which makes sense — it’s the thing we call to “continue” where we left off.

Let’s make a type to represent a continuation:

typealias Continuation<Ret> = (Ret) -> Void

Our CPS version of fetchAvatar could then look like:

func fetchAvatar(user: UUID, c: Continuation<URL>)

In fact, if we rewrite the signature of all the functions from our async example, above, we might notice something striking:

func fetchPortrait(
  user: UUID, 
  c: Continuation<Image>
)
func fetchAvatar(user: UUID, c: Continuation<URL>)
func fetchImage(url: URL, c: Continuation<Image>)

They all take a Continuation type — the only difference is the generic type representing the value they’ll eventually be called with. If we had a way to transform a Continuation<URL> to a Continuation<Image> , we could chain these together!

In other words, given a Continuation<URL> we want a way to apply a transformation (T)->Continuation<U> that results in a new Continuation<Image>. This is a flatMap. And flatMaps are the domain of Monads.

There’s a Monad for That

A Continuation Monad wraps a Continuation. That is, it’s what happens when you render a Continuation, itself, in continuation passing style.

If a Continuation, conceptually, rewrites a value as a function that takes said value as its parameter, then a continuation of a Continuation is a Continuation rewritten as a function that takes said Continuation as its parameter.

Deep breath.

Okay, let’s to try to illustrate this in code:

// A plain old Value:
Value

// Continuation of Value:
(Value)->Void

// Continuation of Continuation of Value:
((Value)->Void)->Void

Defining types for these abstractions as we go will help keep things clear. ContinuationMonad is a continuation of a Continuation:

typealias ContinuationMonad<Value> = 
          (@escaping Continuation<Value>) -> Void

We can create one of these monads with a function that takes the value we eventually want to pass on to the continuation. We can name this function anything we like. init, makeMonad, unit… Khanlou’s post on monads covers a lot of various names traditionally used for monadic operations.

Here, we’re going to name it async:

func async<Value>(_ wrappedValue: Value) 
     -> ContinuationMonad<Value> {
  return { continuation in
    continuation(wrappedValue)
  }
}

This returns a function that, when called with a continuation, calls the continuation with the wrappedValue passed in on creation. In other words, this returns a ContinuationMonad.

Flat the Planet

Or course, our whole goal is to be able to transform between different types of continuations. In the context of a ContinuationMonad, we want to be able to, given a value T from the source monad, create a new monad with a transformed value U. Which is to say:

typealias Transform<T,U> = 
               (T) -> ContinuationMonad<U>

We apply this transform with our friend, flatMap. But the implementation of a flatMap over a continuation of a Continuation is a little intense:

func flatMap<T,U>(
  _ monad: @escaping ContinuationMonad<T>, 
  _ transform: @escaping Transform<T,U>
) -> ContinuationMonad<U> {
  return { continuation in
    monad { wrappedValue in
      transform(wrappedValue)(continuation)
    }
  }
}

Given a ContinuationMonad and a Transform, we return a function that, when called with a Continuation, will:

Unwrap the first monad with an ad-hoc continuation we create that…
Takes the original monad’s value, transforms it into a new monad using the given Transform, and then…
Passes the continuation into this new monad, effectively calling the continuation with our transformed value.

If this causes headaches, we are, at least, in very good company. My best advice is to throw it into a playground and step over it a couple or hundred times. Enlightenment will follow in its own measure.

Once we get over the raw mechanics, the important thing for us to recognize is none of these transformations are actually applied at the time we call flatMap. We return a thing that will call the thing that will apply the transformations when the continuation is passed in. In other words, everything is still asynchronous.

Spicy Curry

With the ContinuationMonad to guide us, our fetchPortrait implementation can create a new monad wrapping the given UUID, then flatMap it into our fetchAvatar operation:

// We’ll make this better. Promise!
func fetchPortrait(
  user: UUID, 
  c: @escaping Continuation<String>
) {
  flatMap(
    async(user),
    { aUser in 
      { aContinuation in 
        fetchAvatar(user: t, c: u) 
      } 
    }
  )
  //...
}

Yikes! What happened in the second half of our flatMap?

Well, remember the flatMap takes a Transform that looks like :

// Transform’s definition:
(T)->ContinuationMonad<U>

or, if we break it down a few steps further:

// Substitute ContinuationMonad’s definition:
(T)->(Continuation<U>)->Void

// Substitute Continuation’s definition:
(T)->((U)->Void)->Void

That’s a tricky shape to fill. And our fetchAvatar’s signature doesn’t match it:

(UUID, (URL)->Void)->Void

Though, actually, if we pull that first UUID argument off of the front, creating new function that takes only the UUID, returning a function that takes what remains of the original parameters… that fits the shape we need exactly:

// What we need:
(T)->((U)->Void)->Void

// fetchAvatar after pulling first argument 
// into its own function:
(UUID)->((URL)->Void)->Void

There’s a functional programming concept called “currying” that does precisely this. The details are probably worth a blog post on their own, and the Point•Free folk have a really good series on this if you want to know more.

But for now, suffice it to say that, given this function:

public func curry<T, U, Z>(
  _ ƒ: @escaping (T, U)->Z
) -> (T) -> (U) -> Z {
  { t in { u in ƒ(t, u) } }
}

and some function that takes two arguments like:

func example(_ i: Int, _ d: Double) -> String {
  "\(i):\(d)"
}

both these expressions are equivalent:

example(42, 33.3)        //> "42:33.3"
curry(example)(42)(33.3) //> "42:33.3"

Which lets us rewrite our messy flatMap above as:

func fetchPortrait(
  user: UUID, 
  c: @escaping Continuation<String>
) {
  flatMap(
    flatMap(
      async(user), 
      curry(fetchAvatar)
    ),
    curry(fetchImage)
  )
}

Much better!

Operator Operation

But hold the phone… the whole point of this was to get rid of nesting in our callbacks, and here we are nesting a bunch of flatMaps instead? How is this an improvement?

In short, there’s a big difference between nested closure implementations (and their captured environments) and nesting identical functions with identical signatures; not the least of which is: we can chain redundant function calls by introducing an operator.

When it comes to declaring an operator, there can be a lot of sturm and drang over the choice of symbol. Haskell uses >>= for a flatMap. That’s good enough for me:

precedencegroup FlatMapOperator { 
  associativity: left 
}
infix operator >>=: FlatMapOperator

func >>=<T,U> (
  lhs: @escaping ContinuationMonad<T>, 
  rhs: @escaping ContinuationMonadTransform<T,U>
) -> ContinuationMonad<U> {
  return flatMap(lhs, rhs)
}

With this, we can rewrite our monad chain, above, as:

async(user)
>>= curry(fetchAvatar)
>>= curry(fetchImage)

Which is feeling pretty nice. Of course, this returns a ContinuationMonad which, as we mentioned above, doesn’t actually do anything on its own. To get it jump into action, we need to give it a continuation.

We could do that with a trailing closure:

(async(user)
 >>= curry(fetchAvatar)
 >>= curry(fetchImage)) { image in
  logImage(image)
}

But more often than not, we’ll have a parent continuation we’ll want to resume when the monad chain completes. Because it’s already a continuation, we don’t need to make a new closure to hold it. We can just apply it to the preceding function.

To make this look pretty, we’ll add a backwards application operator. Haskell uses $ for this, which is problematic in Swift for a number of reasons. So we’re going to steal F#’s <| instead:

precedencegroup BackApplication {
    associativity: left
}
infix operator <|: BackApplication

public func <| <T, U>(ƒ: (T)->U, t: T) -> U {
  return ƒ(t)
}

Now we can chain async operations on our monad with >>= and apply a continuation (which will be called, asynchronously, with the result of the whole monad chain) with <|:

async(user)
>>= curry(fetchAvatar)
>>= curry(fetchImage)
<| logImage

1,800 Words Later…

Not so long ago, we set out on our quest with nothing but a nested mess of async spaghetti:

func fetchPortrait(
  user: UUID, 
  completion: (Image)->Void
) { 
  fetchAvatar(user: user) { url in
    fetchImage(url: url) { image in
      completion(image)
    } 
  }
}

But with a little understanding of continuations (and a handful of monads and operators on loan from functional languages), we’ve ended up with:

func fetchPortrait(
  user: UUID,
  completion: Continuation<Image>
) {
  async(user)
  >>= curry(fetchAvatar)
  >>= curry(fetchImage)
  <| completion
}

Not bad! Makes me feel like there’s plenty of gas left in the tank of the ol’ runtime to get us through these golden years of iOS 12–14 support.

This was a long one with a lot of scattered code, so I’ve pulled everything together into a gist. You ought to be able to paste it right into a Playground and get results — at least in Xcode 12.

Moving Mental State to the Physical

Wed, 25 Nov 2020 01:00:00 -0500

I posted on twitter about how much I like Muse for iPad. People were curious about what was so special about it, and I thought I could sum it up in a tweet or two. But by the third reply in the thread I realized “I should have put this on the blog.” So here it is…

Selections in Muse

Muse does a great many things well, and I could probably do a whole series on little things worth emulating in our apps. But one particularly representative example stands out to me: Selections.

Anyone who’s used a graphics program — your Photoshops, your Pixelmators, your MacPaints — knows there are two ways to make a selection:

Drag a box.
Lasso an arbitrary shape.

Dragging a box is simple and fast: one click, one drag — and the drag can be adjusted in real time so only the click needs to be targeted. Fast. Easy. Minimal twitch factor. But not very precise.

For precision (selecting around a non-box thing without cutting into background) there’s the lasso. It lets you carefully trace the path of the selection you want. Carefully being the operative word. You need to target each and every point along the path as you’re selecting it. Using the lasso is sweaty.

Muse lets you use either a box or a lasso to make selections. No big innovation there. You make lasso selections with the Pencil. It’s very nice to be able to use the iPad’s most precise instrument for Muse’s most precise operation, but that’s not breaking new ground either.

Modality’s All in the Mind

What’s amazing is how Muse presents modality.

See, in Photoshop, etc. tools are modal. Everything behaves differently depending on what tool’s currently selected (what mode the editor is in) and — importantly — this means we, as users, need to manage the state of the tools to get the results we want.

If we want to make a box selection, for example, we have to be in box-selection-mode. If we’re accidentally in lasso-selection-mode instead, we end up drawing a diagonal-squiggle-selection, not the box we had originally intended.

Being developers, we know there’s a variable called currentTool or something buried in Photoshop that keeps track of this mode so that selection operations can refer to it later to know whether to draw a box or a lasso or what have you.

What may not be as clear is that, for the user, this is also state they have to hold in their mental model of the app. They have to consult the “am I in box mode?” in their brain before making a selection because different gestures (drag-a-box vs. trace-a-shape) and different levels of precision (breezy vs. sweaty) will be required, depending.

This means before a user can let muscle memory take over and perform the gesture they know they need to perform, they literally need to context switch. Halt everything, consult state, potentially switch mode, and then attempt to resume the half-subconscious gesture they were trying to make a moment ago.

Let’s Get Physical

So how does Muse deal with this? You make a lasso selection with the Pencil as normal. To make a box selection instead, just hold the Pencil at a low angle, like you were shading with it:

Let’s look at that video again. That little flip of the Pencil in the hand? That’s the context switch. Muse takes it completely out of mental state and turns it into a physical thing, amenable to muscle memory.

This is a level up, but also not unique. Anyone who uses Photoshop does so with one hand on the keyboard so as to hold down one or more modifier keys while working. ⌥⇧⌘-drag for special behavior. That sort of thing.

What impresses me is the careful thought around the interaction. The Muse developers realized they needed precise (lasso) and imprecise (box) selection UI in their app. And they realized a (small p) pencil has precise (line) and imprecise (shade) modes physically built into it.

Connecting those dots isn’t hard, but thinking about a single interaction in our apps carefully enough to see the dots is. It goes to show we shouldn’t take any interaction for granted. Muse certainly doesn’t, and the careful design that results makes it an absolute joy to use.

Debugging Generics in Swift

Wed, 24 Jun 2020 01:00:00 -0500

A friend of mine was having a problem with a generic function they’d written. I’ve simplified it quite a bit to post, but the essence was:

func foo<T>(_ n: T) -> T where T: Numeric {
  return n * (4 as! T)
}

They could call it with an Int just fine, but when calling with a Double, They’d trap:

let i: Int = 5
let d: Double = 5.5
foo(i) //> 20
foo(d) //> 🛑 SIGABRT

Those steeped in the myths and traditions of generics might see the issue right away. But I didn’t. At least not in its original form. And the compiler wasn’t giving me anything. I had to dig deeper.

Thankfully, with generics, that’s easy to do. They are, at the end of the day, just syntactic sugar around defining polymorphic functions. Our generic function above is functionally equivalent to writing out the same function over and over, each time replacing its Ts with one of the set of all the types that meet its requirements (in this case, all types that implement Numeric).

We can do this manually (at least over the small number of types that are interesting to us). And doing so not only gives us a clearer view into our function’s execution, it also gives the compiler an easier path for diagnostics reporting. Both are huge wins whenever we’re trying to debug.

Just look at what happens when we rewrite our function with the types from our example:

func foo(_ n: Int) -> Int {
  return n * (4 as! Int)
}

func foo(_ n: Double) -> Double {
  return n * (4 as! Double)
  // ⚠️ Cast from 'Int' to unrelated type 
  // 'Double' always fails
}

We probably don’t even need the compiler’s warning to see the problem: we can’t downcast from an Int to a Double — the one isn’t down from the other in any type hierarchy.¹

Unwinding our generic function like this also makes solution more obvious. Double (like Numeric… and Int, obviously) implements ExpressibleByIntegerLiteral. So we don’t even need the cast:

func foo(_ n: Int) -> Int {
  return n * 4
}

func foo(_ n: Double) -> Double {
  return n * 4
}

Or, expressed generically:

func foo<T>(_ n: T) -> T where T: Numeric {
  return n * 4
}

1: And it traps because of the as!. Curious why? Ole Begemann has you covered with the magnificent post as, as?, and as!.↩︎

Parse, Don’t Validate

Sat, 09 Nov 2019 01:00:00 -0500

Alexis King’s post “Parse, don’t validate” is the best thing I’ve read in months. And not just for its pitch-perfect use of “cromulent”. Please find some time and commit to reading it all — it will make you a better programmer — but here’s a small taste:

The problem is that validation-based approaches make it extremely difficult or impossible to determine if everything was actually validated up front… The entire program must assume that raising an exception anywhere is not only possible, it’s regularly necessary.

Parsing avoids this problem by stratifying the program into two phases — parsing and execution — where failure due to invalid input can only happen in the first phase. The set of remaining failure modes during execution is minimal by comparison, and they can be handled with the tender care they require.

It sparks in me some new thoughts with regard to my favorite Ben Sandofsky quote:

If the boilerplate gets mind numbing, refactor it into class methods. If that gets to be too much, build some model objects. The goal is to iterate toward your domain model. There’s a reason Apple’s frameworks only get you 80% of the way there. That remaining 20% is called ‘Your App.’

King’s post makes concrete for me how futile it is to pass and occasionally validate data in pursuit of this goal. It’s only through the successive parsing of our data that we iterate towards our domain model. Validating just rearranges deck chairs on the Titanics of our ever-growing codebases.

SwiftUI Layout Gems

Mon, 02 Sep 2019 01:00:00 -0500

One of the first things presented about SwiftUI is that its views determine their own sizes, and that those sizes are fixed … This statement fundamentally changes everything you know about layout. Until you understand all of the repercussions of it, you’ll be constantly feeling like you’re fighting SwiftUI for even the simplest layouts.

–Scott James Remnant, netsplit.com

This is definitly my experience with layout in SwiftUI. It took this masterful series of posts by Scott James Remnant (yes, that Scott James Remnant) to set me straight. I highly recommend starting with ~~“Views Have Fixed Sizes”~~ and continuing to click “Next” until empty.

[Edit: The original site is down, but here’s the captured version from archive.org]

Using Publishers to Prevent Hanging Timers

Sat, 24 Aug 2019 01:00:00 -0500

One of the venerable Foundation APIs to get a Combine extension in Catalina/iOS 13 is the Timer class:

static func publish(
     every interval: TimeInterval, 
     tolerance: TimeInterval? = nil, 
     on runLoop: RunLoop, 
     in mode: RunLoop.Mode, 
     options: RunLoop.SchedulerOptions? = nil) 
-> Timer.TimerPublisher

In practice we’d probably use it something like:

import Foundation
import Combine

let subscription = 
Timer.publish(every: 1.0, on: .main, in: .default)
  .autoconnect()
  .sink { _ in
    print("timer fired")
  }

// Time passes...

subscription.cancel()

Note that Timer.publish returns a ConnectablePublisher meaning we need to call connect or use autoconnect to start it publishing. Otherwise this feels like a pretty straight-forward definition of a timer.

So straight-forward, in fact, that it looks pretty familiar. Here’s how we might have written a timer before Combine:

let timer = 
Timer(timeInterval: 1.0, repeats: true) { _ in
  print("timer fired")
}

RunLoop.main.add(timer, forMode: .default)

// Time passes...

timer.invalidate()

We explicitly add the timer to the run loop instead of using autoconnect to start it. And to stop it we call invalidate on the returned timer ref rather than cancel on an AnyCancellable. But all the same pieces are there. The interval, run loop, closure to execute, etc.

So it’s tempting to say that, if we’re targeting Catalina/iOS 13 but not interested in filtering timer events through a bunch of Combine operators, there’s really no benefit to using Timer’s publisher API.

But this overlooks a major yet somewhat invisible benefit, which is life cycle management.

Let’s say we have a class that uses an old-school timer:

class OldTimer {
  let timer: Timer
  init() {
    timer = 
    Timer(timeInterval: 1.0, repeats: true) { _ in
      print("Old Timer, go!")
    }
    RunLoop.main.add(timer, forMode: .default)
  }
}

var old: OldTimer? = OldTimer()

// ⏱ Wait two seconds ⏱

old = nil

What do we we see in our output?

Old Timer, go!
Old Timer, go!
Old Timer, go!
Old Timer, go!
Old Timer, go!
Old Timer, go!
Old Timer, go!
Old Timer, go!
Old Timer, go!
…

Uh oh! We forgot some crucial cleanup in our deinit:

class OldTimer {
  let timer: Timer
  
  // ...

  deinit {
    timer.invalidate()
  }  
}

Now we get the expected results:

Old Timer, go!
Old Timer, go!

But how easy is it to forget that deinit? I do it practically every time I use a Timer, and often in less obvious circumstances than what’s presented here.

Let’s look at the publisher case:

class NewSchool {
  let subscription: AnyCancellable
  init() {
    subscription = 
    Timer.publish(every:1.0, on:.main, in:.default)
      .autoconnect()
      .sink { _ in
        print("New School, I choose you!")
      }
  }
  
  deinit {
    subscription.cancel()
  }
}

var new: NewSchool? = NewSchool()

// ⏱ Two seconds later ⏱

new = nil

We see:

New School, I choose you!
New School, I choose you!

Not a big difference, right? Here’s the trick, though: unlike a Timer which lives on irrespective of our reference to it, the life cycle of a Subscription is completeley tied up in its value. If it gets set to nil and/or released, it automatically cancels its connection to its publisher.

So in our example, because the default behavior of properties like subscription is to be retained while their object exists and automatically nil’d out when it’s deallocated, we don’t need an explicit dealloc statement at all! In other words:

class NewSchool {
  let subscription: AnyCancellable
  init() {
    subscription = 
    Timer.publish(every:1.0, on:.main, in:.default)
      .autoconnect()
      .sink { _ in
        print("New School, I choose you!")
      }
  }
}

var new: NewSchool? = NewSchool()

// ⏱ Two seconds later ⏱

new = nil

still does exactly what we want it to:

New School, I choose you!
New School, I choose you!

So publishers and subscriptions present a much more intuitive way to think about cancellation, invalidation, and life cycles. And that’s great! But it’s also worth pointing out they make the default, naïve implementation the correct one. This makes them effective protection against bugs of omission — the value of which shouldn’t be underestimated.

Optional, throws, Result, and async/await

Thu, 02 May 2019 01:00:00 -0500

I got to write a post over at NSHipster (😮) this week about the past, present, and glorious future of error handling in Swift and how Result fits in with it all. Let me know what you think!

Exhaustive Properties with Tuples

Sun, 03 Mar 2019 01:00:00 -0500

One thing I really love about Swift is its exhaustive switch statement. As programmers, we live with a creeping dread of change and the unforeseen consequences it can wreck on our carefully calibrated computations. And switch is an excellent hammer with which we can nail down at least one future loose end.

If we have code that calculates how many spaces a character can move in a game, for example:

enum Character {
  case elf, dwarf, human
}


func spaces(for character: Character) -> Int {
  switch character {
  case .elf:
    return 7 // Spritely!
  case .dwarf:
    return 3 // Short legs; big heart.
  case .human:
    return 5 // Even Steven.
  }
}

…and we later add a dragon:

enum Character {
  case elf, dwarf, human, dragon
}

No problem! The Swift compiler let’s us know there’s a spot where we haven’t considered what to do with dragons, and won’t let us continue until we deal with it:

func spaces(for character: Character) -> Int {
  switch character { 🛑 Switch must be exhaustive
    //...
  }
}

This future-proofing is such a comfort to me, I cram everything I can in switches. But sometimes it’s just not feasible. Let’s look at a simple person model. It can hold a firstName and/or a lastName, and put those together in a description:

class Person: CustomStringConvertible {
  var firstName: String?
  var lastName: String?
  

  var description: String {
    return [firstName, lastName]
      .compactMap { $0 }
      .joined(separator: " ")
  }
}

It also has utility methods for letting us know if it has a full name, and for returning either the first or last name, whichever is present, for more informal modes of address:

extension Person {
  var isFullName: Bool {
    guard
      firstName != nil,
      lastName != nil else {
        return false
    }
    return true
  }
  

  var firstOrLast: String? {
    return firstName ?? lastName
  }
}

This all looks fairly straightforward, but I’m terrified. What if later we add a middleName property? Nothing will break, yet everything will be wrong. It will be up to whomever implements middleName to search for all the places it might be relevant¹ and incorporate it.

How can we get switch-like exhaustiveness when dealing with the properties of a type? The first step (and our first clue) is to treat the properties as a set. What if we put them in a tuple?

class Person: CustomStringConvertible {
  var name: (first: String?, last: String?)
}

Accessing the properties of Person is still painless:²

let myPerson = Person()
myPerson.name.first = "Deedlit"

And we can now rewrite description and isFullName in terms of the tuple:³

var description: String {
  let (first, last) = name
  return [first, last]
    .compactMap { $0 }
    .joined(separator: " ")
}


var isFullName: Bool {
  guard case (_?, _?) = name else {
    return false
  }
  return true
}

But firstOrLast, which only depends on a first and last name and doesn’t care if we ever add more, can reference the values of the tuple directly:

var firstOrLast: String? {
  return name.first ?? name.last
}

Now what happens if we add a middle name?

class Person: CustomStringConvertible {
  var name: (
    first: String?, 
    middle: String?, 
    last: String?
  )


  var description: String {
    let (first, last) = name
    🛑 tuples have a different number of elements
	// ...
  }
}



extension Person {
  var isFullName: Bool {
    guard case (_?, _?) = name else {
    🛑 tuples have a different number of elements
    }
	// ...
  }


  var firstOrLast: String? {
    // ...
  }
}

description and isFullName are both flagged with compiler warnings, firstOrLast just keeps on trucking, and I cut my antacid budget by 4×.

So, to be clear, habitually shoving all properties into a tuple won’t scale well. But it is a useful tactic to employ when dealing with models, mocks or anything that has:

naturally constrained state,
logic that depends on the shape of said state, and
a strong affinity towards change in the face of shifting requirements

When we are confronted with such beasts, we can save our future-selves some consternation by popping properties into tuples.

1: Think of all the places extension Person could live if you really want to break out in a cold sweat.↩︎

2: Though, outside the forced reality of a blog example, the Person model should be a struct, its name should be a let, and everything immutable. Still, it’s good to know mutable tuples are a thing. ↩︎

3: The (_?, _?) in isFullName might look odd. It is a combination of the Wildcard Pattern and the Optional Pattern. It means, roughly, “a tuple of two non-optional things.” We’ve talked about the Optional Pattern before, over here.↩︎

Conditional Compilation in Swift

Fri, 27 Jul 2018 01:00:00 -0500

These great posts (part1, part2) from Dave DeLong show off all sorts of cool tricks we can use to get the most out of our .xcconfig files. They’re of particular interest to those targeting disperate plaforms and architectures, but we can all benefit from a little extra xcconfig-fu.

H/T: Michel Tsai (who, by the way, just launched a patrion worthy of your consideration).

Custom Types for Powerful Matching

Mon, 23 Jul 2018 01:00:00 -0500

Most modern apps have to deal with URLs in one way or another. Let’s say we have an embedded WKWebView, for example, and we need to decide how to route tapped links. A naive implementation might look something like this:¹

func webView(_ webView: WKWebView,
     decidePolicyFor action: WKNavigationAction, 
     decisionHandler: @escaping [...]) {
  guard let url = action.request.url else {
    decisionHandler(.cancel)
  }
  let app = UIApplication.shared

  //If the URL has one of these special 
  //schemes, let the OS deal with it.
  if "tel" == url.scheme
     || "sms" == url.scheme
     || "mailto" == url.scheme {
    app.open(url, options: [:]) {_ in}
    decisionHandler(.cancel)

  //Natively handle these paths that
  //have special meaning.
  } else if url.path == "/logout" {
    performLogout()
    decisionHandler(.cancel)

  } else if url.path == "/about" {
    showAbout()
    decisionHandler(.cancel)

  //Otherwise, just load it.
  } else {
    decisionHandler(.allow)
  }
}

As time passes and our code grows, long chains of if...else statements like these are just asking for trouble. They encourage a very imperative style that can be hard to decipher after the fact. And it’s hard to know where to insert new conditionals or how said conditions will affect existing flow.

An “if” by Any Other Name

A better solution might be to arrange everything in a switch… but things get ugly fast:

switch url {
  case let u where u.scheme == "tel"
       || u.scheme == "sms"
       || u.scheme == "mailto":
    app.open(url, options: [:]) {_ in}
    decisionHandler(.cancel)

  case let u where u.path == "/logout":
    performLogout()
	decisionHandler(.cancel)

  case let u where u.path == "/about":
    showAbout()
	decisionHandler(.cancel)

  default:
    decisionHandler(.allow)
}

The problem here is we have no way to directly match the parts of the URL we’re interested in. We have to bind the whole thing and then use a where clause tease out the components we care about. But where is essentially just an if with a different name. The conditional clauses we give it are the same as the ones we passed to if — complete with all the imperative and readability issues we outlined above.

Declarative Types

What we’d really like is a more declarative way to simply tell switch exactly what we want:

switch url {
  case "mailto:":
    //...
  case "/logout":
    //...
}

The big problem here, though, is most URL components we care about are indistinguishable by type. They’re all Strings in Swift. And not only do they all sort of blend together as we read them, the compiler can’t make heads or tails of it.²

So let’s unique everything by adding a few types of our own:

extension URL {
  struct Scheme {
    let value: String
    init(_ value: String) {
      self.value = value
    }
  }

  struct Path {
    let value: String
    init(_ value: String) {
      self.value = value
    }
  }
}

Now we can write:

switch url {
  case URL.Scheme("tel"),
	   URL.Scheme("sms"),
	   URL.Scheme("mailto"):
	app.open(url, options: [:]) {_ in}
	decisionHandler(.cancel)

  case URL.Path("/logout"):
	performLogout()
	decisionHandler(.cancel)

  case URL.Path("/about"):
	showAbout()
	decisionHandler(.cancel)

  default:
	decisionHandler(.allow)
}

And it looks gorgeous! But, of course, none of this compiles because Swift doesn’t understand how to match a Scheme or a Path to a URL:

Expression pattern of type ‘URL.Scheme’ cannot match values of type ‘URL’

No worries. As we talked about earlier we can teach Swift new expression patterns by overloading the ~= operator:

//Given a control expression that evaluates
//to a URL, and our Scheme type for the pattern, 
//Swift will call this to determine a match: 
func ~=(pattern: URL.Scheme, value: URL) -> Bool {
  //We can then use it to compare our `Scheme` 
  //pattern directly to URL’s `scheme` property.
  return pattern.value == value.scheme
}


//Ditto for a URL and our custom Path type:
func ~=(pattern: URL.Path, value: URL) -> Bool {
  return pattern.value == value.path
}

Composition Considerations

One nice side-effect of this “define a type and matching operator” alternative to endless if...else or case...where clauses is it provides a better path for composability.

Imagine our domain logic has some need to match a secure path; that is, a URL with a given path and the added requirement that the scheme is “https”. switchs are good at handling one pattern or another:

switch url {
case URL.Path("/logout"),
     URL.Path("/signout"):
  //kill user credentials when *either*
  //path is encountered.
}

But they’re not so great when it comes to and:

switch url {
case URL.Scheme("https"):
  switch url {
  case URL.Path("/about"):
    //we have to nest our statements to
    //compose a scheme *and* a path.
  }
}

Thankfully we can just define a new type that represents our domain requirements:

extension URL {
  struct SecurePath {
	let value: String
	init(_ value: String) {
	  self.value = value
	}
  }
}

And then compose our ~= overload from existing matchers:

func ~=(pattern: URL.SecurePath, value: URL) -> Bool {
  return URL.Scheme("https") ~= value 
         && URL.Path(pattern.value) ~= value
}

It’s hard to argue with the readability of the results:

switch url {
  case URL.Scheme("tel"),
	   URL.Scheme("sms"),
	   URL.Scheme("mailto"):
	app.open(url, options: [:]) {_ in}
	decisionHandler(.cancel)

  case URL.Path("/logout"),
       URL.Path("/signout"):
	performLogout()
	decisionHandler(.cancel)

  case URL.SecurePath("/about"):
	showAbout()
	decisionHandler(.cancel)

  default:
	decisionHandler(.allow)
}

1: If you’re not familiar with WKWebView’s navigation delegate, don’t fret. The important thing to know is the action contains a URL, and based on that we decide whether we want the web view to load it (decisionHandler(.allow)) or not load so we can do something else instead (decisionHandler(.cancel)).↩︎

2: We could do something “clever” and regex the string looking for a trailing : to denote a scheme, a leading / for a path, or an internal . for a host, etc. Edge cases abound, however. And at that point, we’re essentially reimplementing our own type system on top of String. Swift has a perfectly good type system already, so I’ll leave the implementation (and attendant disillusionment) as an exercise for the reader.↩︎

Optionals as Collections

Thu, 29 Mar 2018 01:00:00 -0500

Sometimes when working on a thing, I get the sense I’m swimming up stream — that it’s just a little too hard and there has to be a better way.

Sometimes this prompts me to do a little more research and I’ll find the solution staring me in the face. But sometimes I continue to miss the obvious, post about it, and rely on the kindness of smarter people to straighten me out.

In the case of my last post on applying optional values to failable initializers, the role of smarter people is played by Ole Begemann, Will Hains, and a bunch of helpful redditors.

TL:DR;

I re-invented the wheel with applyOptional, which is functionally identical to calling flatMap on an optional type.

And given this, Haskell already has an operator for calling flatMap (a.k.a. bind) on an Optional (a.k.a. Maybe) and it’s >>=. To avoid confusion, we should probably use this if an operator proves necessary.

Further, this all sounds familiar enough that I think I might have known it at one point or another. But I never really understood it, not on an intuitive level. When the time came, binding an optional via flatMap never occurred to me.

So in an effort to make the lesson stick this time, I’ve tried to go back to basics. Thus, the rest of this post.¹

Flattened Arrays

First, how on earth does flatMap apply to optionals anyway? Isn’t it supposed to deal with nested arrays or something?

Well, sort of. Let’s start by looking a little more into that nested Array scenario. We can think of a plain ol’ map on an Array like this:

[T].map((T)->U) -> [U]

Which is to say, map is a method on an array of Ts that, given a function that turns a lone T into a U, will return an array of Us.

Now, we can imagine giving our map a function that returns an array of Us instead of a single U, and then we would end up with something like:

[T].map((T)->[U]) -> [[U]]

See how now we’re returned a nested [[U]]? That’s not always super useful. Sometimes we just want [U].

flatMap deals with this by adding an operation that “flattens” the output before returning it. In this case it will unwrap our [[U]] into a simple [U]:

[T].flatMap((T)->[U]) -> [U]

This seems like a useful (if rather niche) utility. But how does it apply to Optionals?

Flattened Optionals

My big mistake was thinking about optionals as just another enum when, in several situations, Swift treats them more like a collection of zero or one elements.

Viewed in this light, the same examples we used above for arrays can be applied to optionals. A map works like this:

T?.map((T)->U) -> U?

That is, given a collection of zero or one Ts and a function that turns a T into a U, map will return a collection of zero or one Us.²

And just as with our array example, we can imagine a scenario where we pass this map a function that returns a collection of zero or one Us instead of a lone U. This would result in:

T?.map((T)->U?) -> U??

Note the Optional<Optional<U>> at the end there. We’d pretty much always want this to be unwrapped or “flattened” a level before we’d use it, and that’s exactly what flatMap on an optional does:³

T?.flatMap((T)->U?) -> U?

Where Have I Seen this Before?

If we think back to the previous post, I was bemoaning how some failable initializers in Foundation such as URL(string:) don’t take optional parameters. But looking at it now, we see the signatures of these existing initializers exactly fit what flatMap expects as a parameter:

//Takes a String, returns a URL?:
URL.init?(string: String)
//Takes a T, returns a U?:
(T)->U?

With no further modification we can pass these initializers into a flapMap on an optional like so:

let urlString: String? = textField.text
let maybeURL = urlString.flatMap(URL.init)

And so it’s now clear to me why URL(string:) doesn’t support optional parameters. It would break compatibility with a crucial part of Swift’s collection-processing toolkit.

But moreover, adding an optional param would be akin to asking URL.init to accept an array of strings. It’s not URL’s responsibility to know which elements of what collections to use to instantiate itself. Instead, it’s our program’s job to whip our collections into the accepted element(s), and pass those on to URL.

And while it’s sometimes difficult to remember Optional can, in this sense, be a collection in need of whipping, it none the less has a full complement of higher order functions (including flatMap) making it up to the challenge, regardless.

1: As the Field Notes folks say, “I’m not writing it down to remember it later, I’m writing it down to remember it now.”↩︎

2: We don’t see this used much in practice because Swift gives us the optional chaining operator as a language feature. Functionally,

let str = maybeURL.map { $0.absoluteString }

and

let str = maybeURL?.absoluteString

are equivalent.↩︎

3: Note this is also the rational for why the recently deceased Sequence.flatMap worked the way it did. If:

[T].map((T)->[U]) -> [[U]]
[T].flatMap((T)->[U]) -> [U]

and

T?.map((T)->U?) -> U??
T?.flatMap((T)->U?) -> U?

then

[T].map((T)->U?) -> [U?]
[T].flatMap((T)->U?) -> [U]

makes a certain amount of sense. Especially if we consider both arrays and optionals to be sequences of zero or more elements.↩︎

Optional Forward Application

Tue, 27 Mar 2018 01:00:00 -0500

UPDATE: Ole Begemann, Will Hains, and a bunch of helpful redditors all point out a fundamental oversight I’ve made here:

My implementation of applyOptional, below, is functionally identical to calling flatMap on an optional type. And given this, there’s already prior art for an operator that calls flatMap (a.k.a. bind) on an Optional (a.k.a. a Maybe monad): >>=.

I talk a little more about this in this post, but the takeaway is, just use the built-in flatMap:

let urlString: String? = textField.text
let maybeURL = urlString.flatMap(URL.init)

And if we want to define an operator for this, we should use >>= instead of my made up |?>:

infix operator >>=
func >>= <T, U>(x: T?, f: (T)->U?) -> U? {
  return x.flatMap(f)
}
let urlString: String? = textField.text
let maybeURL = urlString >>= URL.init

The original post follows:

Swift’s out-of-the-box compatibility with existing ObjC frameworks is an amazing technical feat and one of its greatest strengths. But that doesn’t mean I’m never annoyed when using, say, Foundation. Among my biggest pet peeves is the lack of optional overloads to common failable initializers like URL(string:):

let urlString: String? = textField.text
let maybeURL: URL?
if let someString = urlString {
  maybeURL = URL(string: someString)
} else {
  maybeURL = nil
}
// Do something with `maybeURL`...

It’s wordy. It’s got that dangling uninitialized let just sort of hanging out. It has branching execution for no good reason.

And ultimately it just feels unnecessary. The whole idea of a failable initializer is that it can return a nil in response to invalid input. It seems a small jump to extended the input to include optional types — the .none values of which we would presume to be invalid. Then nils would just pass through.

But for whatever reason, that’s not how the API were translated to Swift. I’ve worked around this in a number of ways over the years. I started out using the nil coalescing operator:

let urlString: String? = textField.text
let maybeURL = URL(string: urlString ?? "🚫")

“🚫” is an invalid URL, so when urlString is nil, maybeURL is nil as well.

I don’t hate this — it’s concise and has a sort of literal readability to it. But it’s always felt like a hack based on undefined behavior. Eventually I moved to a more conventional solution:

extension URL {
  init?(maybeString: String?) {
    guard let string = maybeString else {
      return nil
    }
    self.init(string: string)
  }
}

let urlString: String? = textField.text
let maybeURL = URL(maybeString: urlString)

This works well enough. But it’s just as wordy as our original solution. The only difference is we give it a name behind an extension.

And therein lies another weakness: we have to define an extension like this for every failable initializer we use. There’s a fair amount of boiler plate in each, and there’s always the chance for collisions when extending Foundation like this.

Eventually I settled on generic solution in the form of a free function:

func applyOptional<T, U>
     (_ x: T?, to f: (T)->U?) -> U? {
  guard let someX = x else {
    return nil
  }
  return f(someX)
}

let urlString: String? = textField.text
let maybeURL = applyOptional(urlString,
                  to: URL.init(string:))

This has a lot going for it. Not only can it generically handle optional initializers, it can be applied to functions returning optionals generally. This enhances its potential for reuse and thus its value as an abstraction.

But it’s never felt quite right. The first parameter feels buried. “Optional” isn’t descriptive enough to give me a sense of its purpose. And I keep reading URL.init(string:) as a newly created URL rather than a function reference. Something is missing.

I didn’t realize what until I started watching the excellent Point•Free video series.¹ Early on they create a Swift version of F#’s forward application operator, |>. I realized their implementation was very similar to my applyOptional(_:to:), and that got me thinking about free functions in terms of operators:

infix operator |?>

public func |?> <T, U>(x: T?, f: (T)->U?) -> U? {
  guard let someX = x else {
    return nil
  }
  return f(someX)
}

let urlString: String? = textField.text
let maybeURL = urlString |?> URL.init(string:)

So yeah, I took the triangle operator and put a question mark in it to make it more optional-looking. Nothing ground-breaking, but it feels loads better to use. Freed from their parentheses, the bare urlString and URL.init(string:) stand out in their purpose. And the way the operator points the optional into the function ref makes their relation clear in a way the to: label never quite captured.

Not that there aren’t tradeoffs, of course. applyOptional is way easier to google for than |?>, for one thing. But until Foundation adds init?(string: String?) initializers,² expect my code to be dotted with these little FP gems.

1: If you’re reading this blog, I can’t imagine you wouldn’t find entertainment and value in these videos.

My favorite part? Each one is accompanied by a carefully edited transcription. I don’t always have the time or energy to watch a presentation. Reading is sometimes more comfortable. And transcriptions make searching for half-remembered concepts a snap, as well.↩︎

2: Which I’m still not ruling out…↩︎

Dealing with Weak in Closure-based Delegation

Sun, 18 Mar 2018 01:00:00 -0500

This post by Oleg Dreyman is so clever, clear, and useful, I’m temped to call it a must read.

In a nutshell, using closures for delegates puts the responsibility of ownership management on the delegatee rather than the delegator. But by packaging the delegate into a setter, Oleg shows us we can control how it’s captured with respect to the closure (and, as a bonus, reduce our free-floating closures with more trailing closure syntax).

While I’m not sold this needing to be its own dependency, I’m absolutely going to adopt the pattern post haste. Thanks, Oleg!

Better Strategies Through Types

Sun, 11 Mar 2018 01:00:00 -0500

Figuring Out What Not to Do

Imagine we’ve written a UIControl that wraps a button to do some animations whenever it’s tapped:

class BouncyButton: UIControl {
  private weak var button: UIButton!
   
  override init(frame: CGRect) {
    super.init(frame: frame)

    do {
      let b = UIButton(type: .system)
      addSubview(b)
      button = b
    }
    button.addTarget(self,
         action: #selector(handleTap),
         for: .touchUpInside)
 
	// Set frame or constraints...
  }

  @objc func handleTap() {
    //Do some bouncy animations here...
    sendActions(for: .touchUpInside)
  }
}

We could hardcode our animation in the handleTap() method, but maybe we need our button to bounce different ways in different contexts. Encapsulating the behavior of a thing in a swappable container is a common enough practice in software design that it has its own pattern — the strategy pattern.

In Cocoa, strategies have traditionally be implemented via delegates:

protocol BouncyDelegate {
  func animateBounce(for view: UIView)
}
 
class BouncyButton: UIControl {
  let delegate: BouncyDelegate //🤔
  //...
  
  init(frame: CGRect, delegate: BouncyDelegate) {
    self.delegate = delegate
    //...
  }
  
  @objc func handleTap() {
    delegate.animateBounce(for: button)
    sendActions(for: .touchUpInside)
  }
}

This seems straight-forward enough, but there’s a problem. The delegate is strongly held by our control. You can imagine a view controller with this button in its hierarchy setting itself as the button’s delegate. Then the view controller would own the button, which owns the delegate, which owns the button, which owns… a retain cycle!

For this reason, the Cocoa convention is to make all delegates weak. No problem:

weak let delegate: BouncyDelegate
//🛑: 'weak' must be a mutable variable

Oh, I mean:

weak var delegate: BouncyDelegate
//🛑: 'weak' may not be applied to 
//     non-class-bound protocol

Hmm. We can fix¹ this with:

protocol BouncyDelegate: class { ... }

But this will prevent us from using structs or enums to implement our strategy and, at this point, ought make us a little suspicious of what’s going on.

Something Rotten in the State

We have to limit our delegate to class implementations because delegates are assumed to hold mutable state.

Since they have state, they need to be instantiated. If they need to be instantiated, we have to provision storage for them. If we have to provision storage for them, questions around ownership need to be resolved. Qualifiers like weak and (the implicit) strong become necessary.

If we could somehow define our strategies to be stateless things, all of this would cease to be relevant.

But moreover, the thought of mixing state and strategies ought to give us the heebie-jeebies.² Storing state means a strategy might behave differently depending on the values kept within it. Unless we’re writing a parser, no one wants to have think about every other thing that might have mutated our delegate before us and in what order.³

So we want to do away with state in our strategies. And if we’re going to do away with state, then instances are nothing more than chunks of memory we don’t use but still need to manage ownership of. We should get rid of those, too.

Type Method Acting

So rather than holding our strategy’s implementation in instance methods that need to be instantiated, we’re going to move it all up into type methods on the type.

Let’s start with the protocol:

protocol BouncyDelegate {
  static func animateBounce(for view: UIView)
}

The static here indicates a type conforming to BouncyDelegate must have animageBounce(for:) defined on its type. Anything can technically conform to this, but I like to use enums because they can never be instantiated, even accidentally.

enum ShakeStrategy: BouncyDelegate {
  static func animateBounce(for view: UIButton) {
    let base = CGAffineTransform.identity
    let offset = base.translatedBy(x: 30, y: 0)
    view.transform = offset
    UIView.animate(withDuration: 0.5, delay: 0, 
         usingSpringWithDamping: 0.2, 
         initialSpringVelocity: 0, 
         options: [], 
         animations: { view.transform = base }
         completion: nil)
  }
}

Great! We have our strategy type defined. Now we have to change our button a bit to use it:

class BouncyButton: UIControl {
  let delegate: BouncyDelegate.Type
  //...
  
  init(
       frame: CGRect, 
       delegate: BouncyDelegate.Type) {
    self.delegate = delegate
    //...
  }
  
  @objc func handleTap() {
    delegate.animateBounce(for: button)
    sendActions(for: .touchUpInside)
  }
}

Note we’ve had to change the type of delegate from BouncyDelegate, which would be an instance of a type conforming to our protocol, to BouncyDelegate.Type, which is the conforming type, itself.

We’ll initialize our button by passing in our strategy type like so:

let button = BouncyButton(
     frame: someRect,
     delegate: ShakeStrategy.self)

Note the use of .self to indicate we want to use the type itself as our delegate.

Generic Brand Awareness

If all this .Type and .self stuff feels a little awkward, it’s probably because Swift already supports this kind of thing as a language feature. It has a specific syntax just for passing around types that are used to specialize implementations. We know it as “generics”.

We can rewrite our button like so:

class BouncyButton<Strategy>: UIControl
     where Strategy: BouncyDelegate {
  //...
  
  init(frame: CGRect) {
    //...
  }
  
  @objc func handleTap() {
    Strategy.animateBounce(for: button)s
    sendActions(for: .touchUpInside)
  }
}

Note that not only do we get to drop the ownership qualifiers around our delegate property, we don’t need a delegate property at all! This, in turn, simplifies our init and ditches all the confusing .Type stuff.⁴

The .self stuff disappears, too. We now create our button like so:

let button = 
  BouncyButton<ShakeStrategy>(frame: someRect)

Cool! But a further, easy-to-overlook benefit is how we’ve moved responsibility for specifying strategy away from init params and into the type. Now if we ever find ourselves allergic to angle brackets⁵ we can alias the whole thing away with another of Swift’s type-related language features:

typealias ShakyButton = BouncyButton<ShakeStrategy>
let button = ShakyButton(frame: someRect)

1: Almost. We’ll still have to make BouncyDelegate optional, as well.↩︎

2: The Cocoa convention of passing delegate methods the operative object as their first parameter (i.e. tableView(_:heightForRowAt:)) could be seen as a suggestive push in the direction of stateless delegation.↩︎

3: And those writing parsers wish they didn’t have to.↩︎

4: Though, as Michael Tsai points out, “unlike delegates, the type cannot change at runtime.” Dynamism is a key feature not only of delegates, but also of the strategy pattern, generally. Be aware that once we move to generics, we’re giving that up (though we can still swap out types with .self at runtime, as per the previous example).↩︎

5: Or if we’re shipping a framework and want to, say, restrict 3rd party customization of our controls beyond certain pre-defined combinations of strategies…↩︎

Killing

Thu, 28 Dec 2017 01:00:00 -0500

How many times have we all caught ourselves writing code like this:

func makeNext() -> Int {
  let tmp = state
  state += 1
  return tmp
}

We want to manipulate some state, but we also want to return it in its pre-manipulated condition. In other words we’d like to insert a bit of code right after our return statement:

// No, this doesn't work.
func makeNext() -> Int {
  return state
  state += 1
}

But we can’t because nothing after the return will get executed. So instead we stick our state in a tmp variable, do what we gotta do, and then return the tmp.

So what? It’s just one more line of code, right?

The danger here (and with tmp variables everywhere) is that, by definition, they’re exact copies of types we’re actively working with in the same scope. How they differ isn’t semantically clear, and neither the compiler nor code review can stop us from accidentally substituting one for the other:¹

func makeNext() -> Int {
 let tmp = state
 state += 1
 return state //uh oh!
}

Thankfully Swift does provide a way for us to squeeze code in after the return of a method — the documentation just doesn’t make this immediately obvious:

Use defer to write a block of code that is executed after all other code in the function…

Yay!

…just before the function returns.

Oh… Um… Well it turns out they’re talking about the function returning on the stack and not the return statement executing in code. So doing something like this works perfectly:

func makeNext() -> Int {
  defer {
    state += 1
  }
  return state
}

This is true regardless of whether state has value semantics or not.

Note this not only avoids confusing our original and tmp variables, but now the intent of our code has been made clear:

Before we couldn’t know why we were forking off a tmp unless we analyzed everything that messed with the original and followed it all the way through to the eventual return of its tmp copy.² Here, it’s clear from the get-go we want to do some stuff with state. But first we’re going to return it.

1: Actually, in this trivial example, the compiler will warn us that tmp is unused. But we can easily imagine situations where that will not be the case.↩︎

2: And then, if you’re anything like me, all the way back to the top to find where tmp was made in an attempt to remember what it was before we changed it.↩︎

Much Ado About iOS App Architecture

Wed, 08 Nov 2017 01:00:00 -0500

Finally an architecture think piece for the rest of us:

PSA: No one is forcing you to implement multiple DataSources in one Controller. To initiate network calls in viewDidLoad. To parse JSONs in UIViewController. To hard-wire Views with Singleton instances.

If you do that, it’s your fault; don’t blame MVC.

I whole-heartedly endorce all the advice Aleksandar gives within.

(Thanks to Ryan for the link!)

Moving Safety into Types

Sun, 15 Oct 2017 01:00:00 -0500

Let’s say we have a truck. We want it to be safe, so we give it some seatbelts and airbags.

struct Truck {
  var seatbeltFastened: Bool
  var airbagsEnabled: Bool
}

And because we care about safety, we don’t want to let the truck drive unless the seatbelts are fastened.

extension Truck {
  func drive() throws {
    guard seatbeltFastened else {
      throw SafetyError.seatbelt
    }
	guard airbagsEnabled else {
      throw SafetyError.airbag
    }
    // drive away...
  }
}

Now we can drive with confidence:

do {
  myTruck.drive()
} catch {
  print("Safety violation! Driving disabled!")
}

This is pretty nice. To be safe, we have to verify the seatbelt is fastened and the airbags are enabled before we drive. By putting the check in drive() itself, we don’t have to remember to make the check every time we use the truck. And throws gives us a handy way to recover from any exceptional situations where driving isn’t safe.

Here’s the thing about throws, though; it tends to leak up into abstractions built on top of it.

Let’s say we’re building a shipping API, for example. We might want to ship a package via a truck:

func ship(package: Package, truck: Truck) throws {
  truck.add(package)
  try truck.drive() 
}

Our ship(package:, truck:) function looks pretty clean, but note that it’s marked throws. Some logic around how our truck drives has leaked up into our shipping logic, forcing us to deal with it whenever we ship:

do {
  ship(package: myPackage, truck: myTruck)
} catch {
  //???
}

This exposes a few problems:

We’re just trying to ship a package. We shouldn’t have to manage trucks to do that.
Even if we wanted to manage trucks, it’s not clear from calling ship() that any errors will come from driving or that the solution might be to, say, fasten seatbelts.¹
We have to write this error checking code every time we ship something — even when using the same truck!

We want our truck to be safe. But if we validate its safety when we use it, we leak details up to anything that calls it, limiting its composability.

This is an example of complected concerns. We have two concepts here, driving and safety. We have to pull the two apart:

extension Truck {
  func validateSafety() throws {
    guard seatbeltFastened else {
      throw SafetyError.seatbelt
    }
	guard airbagsEnabled else {
      throw SafetyError.airbag
    }
  }

  func drive() {
    // just drive...
  }
}

This is cool in the sense that, having separated our validation from action, ship(...) no longer has to care about the state of the Truck we pass it:

do {
  try myTruck.validateSafety()
  ship(package: myPackage, truck: myTruck)
} catch {
  print("Safety Violation!")
}

But now we have to remember to check the safety of our truck every time before we use it! If we forget once, disaster.²

So what if instead of verifying safety in a method, we make safety a feature of a type?

struct SafeTruck {
  let value: Truck
  
  init(_ truck: Truck) throws {
	try truck.validateSafety()
	value = truck
  }
}

We’ve taken Truck and wrapped it in a new type, SafeTruck, which can only be created with a Truck that meets its safety requirements.

Which means we can now rewrite ship(package:, truck:) to take a SafeTruck instead of a Truck:

func ship(package: Package, truck: SafeTruck) {
  truck.value.add(package)
  truck.value.drive()
}

Now Swift does all the work for us:

ship(package: myPackage, truck: myTruck)
//🛑 Cannot convert value of type 'Truck' 
//   to expected argument type 'SafeTruck'

This isn’t magic. We haven’t somehow abstracted away the need to catch validation errors. We’ve just moved the implicit check we’d previously made whenever we used a truck into an explicit check we make on initialization:

do {
  let safeTruck = try SafeTruck(myTruck)
} catch {
  print("Truck is not safe!")
}

First, note that by moving validation from a thing that happens on use (where it could be buried beneath twelve layers of abstraction) to something that happens on creation, we’ve front-loaded it. We now get to handle errors where we have the most specific knowledge about them. To put it another way: there’s little doubt why try SafeTruck(myTruck) might fail.

But we’ve also isolated our checks. We only have to write try...catch once (on initialization). After that (if our use case permits) we can reuse our safe, validated truck without having to recheck its safety.³

And because we’ve made safety a feature of our type, we have all the brains of Swift’s tireless type checker behind us, making sure we never make a mistake.

After all, when given a type safe language it only makes sense to put safety in types.

1: True, we can deduce this information by matching for a specific error (SafetyError.seatbelt in this case). But knowing the specific error requires we know the implementation of ship(...) well enough to know what methods on Truck get called — and then know Truck well enough to know which methods throw and why.↩︎

2: Whereby “disaster” I mean “a bug”.↩︎

3: Note this is only true because Truck is a value type. If SafeTruck stored a reference to a truck instead of a value, truck could be mutated behind its back. There’d be no way to guarantee a truck that was safe at initialization would still be safe later when actually used.↩︎

Deep Thought of the Day Expressed by Reference to Increasingly Irrelevant and Soon to be Forgotten Cartoon Characters

Wed, 20 Sep 2017 01:00:00 -0500

Wile E. Coyote’s problem wasn’t that the Roadrunner was fast (roadrunners top out at 32 km/h, coyotes at 69km/h), it was that he was wily. If he did the obvious, simplest thing and ran the bird down instead of trying to be clever, he’d have no difficulty.

Meditate on this before writing each line of code.

Why Coroutines

Mon, 04 Sep 2017 01:00:00 -0500

Remember how, when Swift introduced us to the concept of Optional, all of a sudden explanations around the theory and implementation of monads became relevant¹ and interesting?² Thanks to the await/async proposal currently being discussed in Swift evolution, the same is about to happen to another rather computer-sciencey concept: coroutines.

We’re still a long way off from any concrete implementation of coroutines in Swift, but that doesn’t mean we can’t explore some of the conceptual underpinnings around how and why we might like to use them.

But to do that we need to begin at the beginning.

Starting with Subroutines

What’s a subroutine? Technically it’s a sequence of program instructions that perform a specific task, packaged as a unit. But we know it better as simple, everyday function.³

We tend to take functions for granted, and many of their characteristics get overlooked as just “the way things work”. For example, the execution of instructions in a function always starts at the top, never in the middle. And when we leave a function (via explicit or implicit return) we tear it down and can never get back into it:

func makeSplines() -> [Spline] {
  var splines = [Spline(1)] // We always start here
  return splines            // Once we leave here…
  splines.append(Spline(2)) // …this never happens.
}

Again, this is so familiar to us it hardly seems worth mentioning. This is just the way functions work. But it’s not always desirable. Consider the following:

func reticulate(splines: [Spline]) -> [Spline] {
  let encabulated = encabulate(splines)
  let frobbed = frob(encabulated)
  return frobbed
}

Because subroutines always start at the top and can only exit once, any call to reticulate has to wait for encabulate and frob to complete before moving on. If these subroutines block us for a long time, we might wish we could return from reticulate early to do some work. But as we saw above, once we exit we can never get back — everything after the return gets thrown away.

Handling Completion Handlers

The customary way of working around this in Swift is with completion handlers:

func reticulate(splines: [Spline],
                completion: ([Spline]) -> Void) {
  encabulate(splines) { encabulated in
    frob(encabulated) { frobbed in
      completion(frobbed)
    }
  }
  return
}

But let’s examine what we’ve actually done here. We’ve moved the entire body of reticulate into closures passed to encabulate and frob. Then we moved all our return values into these closures' parameters. This frees up reticulate to exit immediately because it has no body left to execute and no values left to return.

But remember, subroutines are thrown out the moment they exit. If that’s true and reticulate returns before encabulate or frob are done with their work, how does any of this still exist when we try to run their completion handlers?

The answer lies in our use of closures. From the section on closures in The Swift Programming Language:

A closure can capture constants and variables from the surrounding context in which it is defined. The closure can then refer to and modify the values of those constants and variables from within its body, even if the original scope that defined the constants and variables no longer exists.

We can see this even more clearly if we do a little work in reticulate before calling encabulate:

func reticulate(splines: [Spline],
                completion: ([Spline]) -> Void) {
  let sorted = splines.sorted
  let reversed = sorted.reversed()
  encabulate(splines) { encabulated in
    completion(encabulated + sorted + reversed)
  }
  return
}

Here we see that not only does our completion closure still exist, it’s able to make use of values defined in reticulate long after it’s exited.

In fact, from a certain point of view, when we define this closure we’re saving the state and position of execution within reticulate. And when we run the closure, we’re sort of resuming execution of reticulate right where it left off.

When a closure is used to preserve the execution environment of a routine like this, it’s called a continuation. And passing continuations into other routines to be called in lieu of returning is known as continuation passing style (CPS).

Wrangling Continuations with Coroutines

All of which is a pretty cool trick! But it’s also messy:

func reticulate(splines: [Spline],
                completion: ([Spline]) -> Void) {
  // ❶ Execution starts here.
  // ❷ But immediately jumps over this...
  encabulate(splines) { encabulated in
    // ❹ sometime later this is called...
    frob(encabulated) { frobbed in
      // ❻ finally we call the completion
      // which acts like a return even though 
      // it's deeply nested.
      completion(frobbed)
    }
    // ❺ ...but returns immediately
  }
  // ❸ ...and returns down here
  return
}

Between the rat’s nest of closures and the execution path that bounces up and down like an EKG, this CPS syntax is far from ideal. All we really want is a way to say “suspend self, pass control, be ready to resume.” But the concept is so antithetical to the core definition of a subroutine (start at top, exit once forever) that it’s hard to express.

Enter coroutines.⁴

Coroutines are different from subroutines. Actually, they’re a more general form of subroutines that don’t follow the “has to start at top” and “can only exit once” rules. Instead, coroutines can exit whenever they call other coroutines. And the next time they’re called, instead of starting from the top again, they pick up right where they left off.

This makes them naturally suited to expressing the “suspend self, pass control, be ready to resume” concept subroutines have such trouble with. To a coroutine, that’s just a simple call. They don’t need to pass around all that continuation baggage.⁵

Once we have the ability to define coroutines, we can rewrite our example (using the proposed Swift syntax) as simply:

func reticulate(splines: [Spline])
     async -> [Splines] {
  let encabulated = await encabulate(splines)
  let frobbed = await frob(encabulated)
  return frobbed
}

The async in the func declaration marks this as a coroutine. The await operator marks locations the coroutine can suspend itself (and, later, resume from).

Compare this to our original, blocking piece of code:

func reticulate(splines: [Spline]) -> [Spline] {
  let encabulated = encabulate(splines)
  let frobbed = frob(encabulated)
  return frobbed
}

We can see that simply switching from a subroutine to a coroutine gives us our desired non-blocking behavior with near identical expressiveness and zero boilerplate.

The Future (and Futures?)

And that’s just the tip of the coroutine iceberg. They’re the foundation of handy abstractions like Actors and Futures. They’re an incredible tool for parsing and lexing.

And, if we think about it, coroutines are essentially tiny little state machines. What can’t we do with tiny little state machines?!

Exploring all these will have to wait for future posts, though. Probably after we get a Swift implementation to play around with. Let’s keep our fingers crossed for v5!

1: For geeky values of “relevant”.↩︎

2: For highly geeky values of “interesting”.↩︎

3: Or, in cases where the subroutine has access to the state of an object, method.t↩︎

4: FINALLY! ↩︎

5: At least conceptually. Coroutines have to stash the state of their execution environment somewhere. And in theory Swift’s coroutine implementation could just be sugar for rewriting

let foo = await bar()
//rest of the body

into

bar(continuation: { foo in
  //rest of the body
})

But as an abstraction, coroutines lets us think about suspending and resuming rather than passing continuations. And they do this regardless of how they “actually” work under the hood.↩︎

Author's Note

Wed, 16 Aug 2017 01:00:00 -0500

Some of you have probably noticed I almost never use the second person here (and rarely the first). It’s because I don’t feel like I’m writing to you. I feel like we’re working together, here. Trying to understand the misunderstood and fix the broken. Figuring it out.

But now I’m writing to you.

I’m asking you, actually. I’m asking, “What do you think about the Google manifesto?”

Do you think it’s been blown out of proportion? That maybe it made some good points? Do you think there’s an equivalence between diverse, inclusive speech and speech against diversity and inclusion?

Fair enough. How about the Nazis who showed up in Charlottesville?

They have the same manifesto. Do you support them? If you’ve already bought into the genetic inferiority of all women, it’s really not much of a jump to throw blacks and jews on the fire as well, is it?

If you believe we have to be “open and honest” about women’s genetic limitations so we can “help” them find their proper role in tech, maybe you would stand arm-in-arm with the alt-right to defend that statue of Robert E. Lee? Lee, who wrote “the blacks are immeasurably better off” as slaves and “the painful discipline they are undergoing, is necessary for their instruction as a race” and “will prepare & lead them to better things.” It’s the same manifesto.

The Charlottesville Nazis, the alt-right, who proudly march alongside them, our president, who makes excuses for each, and this Google manifesto prat — they are all of a piece and they are all selling the same scam. Support for one is support for all.

And support of any means you will find no support here. There will never be a “we” that includes you. Your only goal is to misinform and break.

We’re here to understand and fix.

Lazy Cartesian Products in Swift

Sun, 30 Jul 2017 01:00:00 -0500

Would you like to play a game?

Let’s play some battleship! Assuming a standard 10x10 board, we’ll need two collections:

let xs = 1...10
let ys = ["A", "B", "C", "D", "E", 
          "F", "G", "H", "I", "J"]

If we wanted to hit every square on the grid, we’d have to iterate over both lists in a nested loop. ¹

for x in xs {
  for y in ys {
    target(x, y)
  }
}

There’s nothing wrong with this as far as it goes. But it doesn’t do a great job of expressing what we’re actually trying to accomplish — that is, iterating over every ordered pair of ys and xs.

A more declarative way to go about our task might be to generate a new collection which is explicitly the cartesian product of the two sets, and iterate over that:

product(xs, ys).forEach { x, y in
  target(x, y)
}

Great! Only one minor problem: product doesn’t exist.

Force Majeure

Building something like product isn’t super hard. The trickiest part is getting all the generics right so it can be used with, say, a closed range just as well as with an array.

func product<X, Y>(_ xs: X, _ ys: Y) ->
  [(X.Element, Y.Element)]
  where X: Collection, Y: Collection {
    var orderedPairs: [(X.Element, Y.Element)] = []
    for x in xs {
      for y in ys {
        orderedPairs.append((x, y))
      }
    }
    return orderedPairs
 }

But when we calculate all the ordered pairs of two sets, the size of the resultant set is (as the name implies) the product of both sets. That’s no big deal when we’re talking a 10x10 grid. But if we’re dealing with 10k elements, we can benefit from a more lazy approach that stores the individual sets and generates their products on the fly, as needed.

Wall’s First Virtue

Let’s start by building an iterator:

public struct CartesianProductIterator<X, Y>: 
     IteratorProtocol where
     X: IteratorProtocol, 
     Y: Collection {

  public typealias Element = (X.Element, Y.Element)
 
  public mutating func next() -> Element? {
    //...
  }
}

Why is our generic type X an iterator but we force Y to conform to Collection? If you look at the nested loop in our naive example above, you’ll see that while we iterate over xs only once, we actually loop over ys a number of times (an xs.count number of times, to be precise).

IteratorProtocol allows us to iterate over a set exactly once, so it’s perfect for our X type. But only Collection guarantees us the ability to non-destructively traverse a sequence over and over. So Y must be a little more constrained.

Let’s add an initializer to store our iterator, collection, and related curiosities as properties:

private var xIt: X
private let yCol: Y
 
private var x: X.Element?
private var yIt: Y.Iterator

public init(xs: X, ys: Y) {
  xIt = xs
  yCol = ys
 
  x = xIt.next()
  yIt = yCol.makeIterator()
}

First note xIt is a var. Iterators mutate themselves in the course of serving up next(), so our copy of xs must be mutable.

Also, our ultimate goal here is to take values from xIt and for each of them iterate over the all the values of yCol. We prep for this by pulling the first value out of xIt into x and making an iterator for yCol called yIt.

And note x needs to be optional. We’ll ultimately iterate over xIt until we hit the end — and we’ll know we hit the end when x is nil.²

With all that settled, let’s move on to our implementation of next().

The NeXT Step

The first step of next() is simple; pull a value out of yIt each time it’s called and pair it with the same ol' x we set in the initializer (providing, of course, x isn’t nil)

public mutating func next() -> Element? {
  guard let someX = x else {
    return nil
  }
 
  guard let someY = yIt.next() else {
    return nil
  }
 	 
  return (someX, someY)
}

There. Now each call to next() returns x and whatever the next value of yIt is. But what do we do once we hit the end of yIt? We want to bump x to the next value of xIt, create a new yIt from our collection — and then do the whole thing over again.

Anytime we say to ourselves “…and then do the whole thing over again,” it’s a sign recursion is in our future.

The End is the Beginning is the End

There’s nothing magical about recursion. To do it, we just need to call a method from within the implementation of itself. We’ll do it here when we run out of values in yIt:

public mutating func next() -> Element? {
  guard let someX = x else {
    return nil
  }
 
  guard let someY = yIt.next() else {
    return next() //Recursion!
  }
 	 
  return (someX, someY)
}

But there are two things we need to pay attention to whenever we write recursive routines.

The first is making sure we don’t loop indefinitely. We’ll do that by setting conditions for terminating the recursion, and then making sure we move towards that condition with each iteration.

Our termination condition already exists. It’s that top guard. If x is ever nil, we’re out.

So all we have to do is make sure we’re moving towards a state where x is nil:

public mutating func next() -> Element? {
  guard let someX = x else {
    return nil
  }
 
  guard let someY = yIt.next() else {
	    yIt = yCol.makeIterator()
	    x = xIt.next()
	    return next()
	  }
 	 
  return (someX, someY)
}

There. Now every time we hit the end of yIt, we not only make a new one from our collection, but we also pull the next x from xIt. Eventually, xIt will run out of elements, and x will be nil. End of recursion.

Adventures in Meta

The second thing to look out for when writing recursively is blowing the stack. A stack overflow happens when you call too many functions in a row without returning.³

We can easily see how recursion might cause this to happen. Basically, when we call next() from inside next() we dig one level deeper in the stack. If calling next() in next() causes us to call next(), now we’re another level deep. Get too deep, and we error out with a busted stack.

Thankfully we can see the only time we call next() from inside next() is when yIt.next() returns nil. So the only way we can dig deeper in the stack is if yIt.next() returns nil many times in a row. And the only way that could happen is if yCol is empty.⁴

So we’ll short circuit that specific case with a guard:

public mutating func next() -> Element? {
  guard !yCol.isEmpty else {
    return nil
  }
 
  guard let someX = x else {
    return nil
  }
 
  guard let someY = yIt.next() else {
	    yIt = yCol.makeIterator()
	    x = xIt.next()
	    return next()
	  }
 	 
  return (someX, someY)
}

Free as in Function

And so, finally, we can lazily iterate over every ordered pair of our collections — all while only storing the collections themselves, not their product. But the syntax is a bit awkward:

let xs = 1...10
let ys = ["A", "B", "C", "D", "E", 
          "F", "G", "H", "I", "J"]
var it = CartesianProductIterator(
     xs: xs.makeIterator(), 
     ys: ys)
while let (x, y) = it.next() {
  target(x, y)
}

Let’s wrap this in a Sequence to get access to for...in, forEach, and the rest.

public struct CartesianProductSequence<X, Y>: 
     Sequence where 
     X: Sequence,
     Y: Collection {
  public typealias Iterator =
       CartesianProductIterator<X.Iterator, Y>
  
  private let xs: X
  private let ys: Y
  
  public init(xs: X, ys: Y) {
    self.xs = xs
    self.ys = ys
  }
  
  public func makeIterator() -> Iterator {
    return Iterator(xs: xs.makeIterator(), 
                    ys: ys)
  }
}

And as a finishing touch let’s add a a top-level function to make chaining little more readable:

public func product<X, Y>(_ xs: X, _ ys: Y) ->
     CartesianProductSequence<X, Y> where 
     X: Sequence, 
     Y: Collection {
  return CartesianProductSequence(xs: xs, ys: ys)
}

And just like that, our battleship dreams have become reality:

let xs = 1...10
let ys = ["A", "B", "C", "D", "E",
          "F", "G", "H", "I", "J"]

product(xs, ys).forEach { x, y in
  target(x, y)
}

As ever, here’s a gist of all this together in one place. Compliments of the house.

1: I know Battleship™ was invented before Descartes or something, and insists on calling out the lettered Y axis before the numbered X one. I tried a version of this post where the imaginary target(_:_:) function took its y parameter before the x. I was constitutionally incapable of publishing it.↩︎

2: Or it could be nil right now. If xIt is an iterator over an empty set, x will be nil by the end of initialization.↩︎

3: Ironically, I didn’t find the answer here particularly compelling.↩︎

4: Specifically: if yCol is empty, then every time we call next(), we’re going to immediately call return next() over and over again until we hit the end of xIt. If xIt is long, this could easily be enough to overflow the stack.↩︎

Update: Matching NSErrors

Mon, 24 Jul 2017 01:00:00 -0500

Good news, everyone!

While my original post on this topic might be of some small interest in a general “strategies for using expression patterns” kind of way, Swift provides a much better solution for the specific problem of matching NSErrors.

Joe Groff tweets:

NSErrors are bridged to error structs in Swift.

What does that mean in practice? You can find all the gory details in SE-0112, but the long and the short of it is, depending on the domain of a given NSError, Swift automatically bridges it to a struct describing that domain. In the case of NSURLErrorDomain, for example, Swift will bridge to a URLError:

let error = NSError(domain: NSURLErrorDomain,
                code: NSURLErrorTimedOut)
error is URLError //> true

This alone lets us deal with NSErrors in a much more declarative way without thinking about domains (and that’s not to mention all the goodies it gives us that we used to have to dig through userInfo for — like failingURL!)

But there’s more:

Looks like Foundation provides the ~=(T.Code, T) matcher for you.

So to match a timeout in Swift without writing any code, it’s actually as simple as:

catch URLError.timedOut {
  print("timed out!")
}

Wow! As Doug Gregor writes,

You shouldn’t need to match on NSError nowadays, unless someone is vending an error code not marked with NS_ERROR_ENUM.

I wish I had learned about this a lot earlier. Spread the word! Please and thank you.

Matching NSError in a catch

Sun, 23 Jul 2017 01:00:00 -0500

EXCITING UPDATE!

Swift is way more on top of this than I originally gave it credit for. The TL;DR is you can actually match NSErrors using their structs like so:

catch URLError.timedOut {
  print("timed out!")
}

The updated post over here has all the details.

For context, the rest of the original is provided blow. But seriously, check out the update.

Say we’re writing some sort of networking library on top of URLSession. We might define some domain-specific errors that only make sense in the context of our library — unexpected headers or things like that:

enum RequestError: Error {
  case missingContentType
  case missingBody
  //...
}

And these would be really easy for a client using our library to catch:

let net = AmazingNetworkThing()
do {
  try net.fetchRequest(myRequest)
} catch RequestError.missingContentType {
  print("unknown content type")
} catch {
  //...
}

But the vast majority of network-related errors would actually be raised by the URL loading system itself. And that’s Foundation-level API, which means it raises NSErrors. Which, in turn, means a consumer of our library would have to catch a simple timeout something like:

do {
  try net.fetchRequest(myRequest)
} catch let error as NSError where
     error.domain == NSURLErrorDomain &&
     error.code == NSURLErrorTimedOut {
  print("timed out!")
}

By comparison, this feels overly wordy and very imperative.

We could, of course, catch every NSError thrown by URLSession in our library, and wrap it in a custom enum-based error for easier matching by the client. But a few problems with this approach:

That’s a lot of boilerplate. NSURLErrorDomain defines constants for 49 error codes. And there could be more that are undocumented. Which brings us to…
We don’t control URLSession. By abstracting over part of its API in our library, we’re putting ourselves on the hook for keeping pace with Apple devs from point-release to point-release. And they have a bigger team than ours. Which also suggests…
URLSession is much more widely adopted than our library. Consumers of our lib way down the stack might be expecting a NSURLErrorDomain error rather than our custom, one-off wrapper.

So rather than wrapping the error, a better solution is to wrap the matcher.

struct ErrorMatcher {
  let domain: String
  let code: Int
}
 
func ~=(p: ErrorMatcher, v: Error) -> Bool {
  return 
     p.domain == (v as NSError).domain &&
     p.code == (v as NSError).code
}

See this post for more on that funky ~= operator.

Using this, we can more elegantly and declaratively match any NSError:

do {
  try net.fetchRequest(myRequest)
} catch ErrorMatcher(
     domain: NSURLErrorDomain,
     code: NSURLErrorTimedOut) {
  print("timed out!")
}

And if we were to add a little sugar for a domain of particular concern to us, well who would blame us?

extension ErrorMatcher {
  static func urlDomain(_ c: Int) -> ErrorMatcher {
    return ErrorMatcher(
       domain: NSURLErrorDomain, 
       code: c)
}
 
// Then...
do {
  try net.fetchRequest(myRequest)
} catch ErrorMatcher.urlDomain(NSURLErrorTimedOut){
  print("timed out!")
}

And if a given domain/code pair were common enough, we could even:

extension ErrorMatcher {  
  static let urlTimeout = 
     ErrorMatcher.urlDomain(NSURLErrorTimedOut)
}

// Thus...
do {
  try net.fetchRequest(myRequest)
} catch ErrorMatcher.urlTimeout {
  print("timed out!")
}

Thankfully we don’t have to toss out all these existing, localized, very well documented NSError babies with the bath water of imperative matching. Leveraging Swift’s expression patterns, we can have declarative enum-like matching in our catch clauses — even with NSErrors.