Daniel Inoa

🌯 Ternary Unwrapping in Swift

2017-11-20T00:00:00+00:00

The Issue

Often enough I find myself writing something like this:

let foo: Foo
if let unwrappedDependency = optionalDependency {
    foo = Foo(unwrappedDependency)
} else {
    foo = Foo(fallback)
}

Here I have a foo that needs to be instantiated but its dependency is an optional that has to be dealt with first. This is easily solved by unwrapping said optional through an if-let or guard-let statement. Simple, but it takes just too many lines (depending how you count) to express such a simple flow of statements, which could potentially be repeated many times throughout a codebase. This calls for a more elegant solution.

Swift already comes with some great constructs like the ternary and nil-coalescing operators that help in writing more expressive code and reducing verbosity for code as the one described above.

// Nil Coalescing Operator
let optionalNumber: Int? = ...
let number: Int = optionalNumber ?? nonOptionalfallback

// Ternary Conditional Operator
let condition: Bool = ...
let number: Int = condition ? 1 : 0

However, neither of these operators would be helpful in satisfying the requirements for an inline statement that:

evaluates an optional
provides a path for a successful unwrapping
provides a path if the unwrapping fails

The Solution

Since there’s no operator that meets those requirements, we can then leverage Swift’s ability to define and implement a new operator that would allow us to do just that by combining the ternary conditional and nil-coalescing operators. I’m going to call it ternary unwrapping operator, and it looks like this:

let _ = optional ?? { unwrapped in ... } | ...

and it allows us to simplify the aforementioned flow like this:

let foo: Foo = optionalDependency ?? { Foo($0) } | Foo(fallback)

Let’s dissect this:

Between = and ?? we have an optional that’s to be evaluated.
If said optional can be safely unwrapped then the statement between ?? and | is executed. Here we have a closure that forwards the unwrapped optional and is used to create an instance of the expected return type (in this case Foo).
The statement after | serves as a fallback and must also resolve to an instance of the expected return type.

Use Case

Out of all the many scenarios where this operator could be useful, I’ve found that it is especially useful when doing string interpolation with an optional.

Instead of doing this:

// This approach is overwrought.
let optionalNumber: Int? = 1
let sentence: String?
if let number = optionalNumber {
    sentence = "My favorite number is \(number)"
} else {
    sentence = nil
}

or this:

// This approach force unwraps which isn't ideal.
let optionalNumber: Int? = 1
let sentence: String? = optionalNumber != nil ? "My favorite number is \(optionalNumber!)" : nil 

We could do this instead:

// This approach is concise and leverages the ternary unwrapping operator.
let optionalNumber: Int? = 1
let sentence = optionalNumber ?? { "My favorite number is \($0)" } | nil

Under The Hood

This ternary unwrapping operator is in fact 2 infix operators used in conjunction.

precedencegroup Group { associativity: right }

infix operator ??: Group
func ?? <I, O>(_ input: I?,
               _ handler: (lhs: (I) -> O, rhs: () -> O)) -> O {
    guard let input = input else {
        return handler.rhs()
    }
    return handler.lhs(input)
}

infix operator |: Group
func | <I, O>(_ lhs: @escaping (I) -> O,
              _ rhs: @autoclosure @escaping () -> O) -> ((I) -> O, () -> O) {
    return (lhs, rhs)
}

This first operator, func ??, takes 2 parameters: an optional and a tuple. This function ?? by itself is in fact sufficient as an operator. However, func | is needed to improve the style that match that of a ternary operator.
The second operator, func |, acts as a façade by taking 2 closures and returning them in a tuple; later used by ??.

I (input) and O (output) describe the type of the optional argument and that of the returning value (used in the assignment), respectively.

Closing Thoughts

One of my main priorities as a developer is to improve the readability of the code I write, especially if it is to be reviewed by my peers. I’d like to believe that what the ternary conditional operator has done for if-else statement, this new operator could for the if-let-else unwrapping statement; helping developers write code that will be easy for others to understand.

This ternary unwrapping operator, however, is best suited for cases such as when the instantiation or assignment of an object/value depends on 1 optional dependency needing to be unwrapped. For more complex cases it might be wiser to stick with if-let and guard-let. As always, all the operators described here are best used sparingly when readability of code can truly be improved, and not just to write fancy or unreasonably terse code.

Did you find this interesting and would you like to experiment with it? Check out the sample playground.

Thanks for reading!

🔗 Function Composition in Swift

2017-10-31T00:00:00+00:00

It’s common to perform an operation on a value and use the resulting value of that operation as the argument for a subsequent operation, and so on.

// Definitions

func square(_ x: Int) -> Int {
    return x * x
}

func increment(_ x: Int) -> Int {
    return x + 1
}

func half(_ x: Int) -> Int {
    return x / 2
}

func describe(_ val: CustomStringConvertible) -> String {
    return "The resulting value is: \(val)"
}

// Usage

describe(increment(square(half(6)))) // "The resulting value is: 10"

This works fine but the code quickly starts looking like Racket, and becomes hard to unpack. Another way to do this same thing is by leveraging function composition, which entails chaining many functions together into one. This idea of concatenating functions can be accomplished in Swift by taking advantage of generics and the infix operator.

// Custom Operator Definition

precedencegroup Group { associativity: left }
infix operator >>>: Group
func >>> <A, B, C>(_ lhs: @escaping (A) -> B,
                   _ rhs: @escaping (B) -> C) -> (A) -> C {
    return { rhs(lhs($0)) }
}

Here we have a function that takes 2 parameters and returns a closure.

The first parameter in >>> is a function that takes 1 parameter of type A and returns an instance of type B.
The second parameter in >>> is a function that takes 1 parameter of type B (this is where the concatenation occurs) and returns an instance of type C.
Lastly, >>> returns yet another function which takes 1 parameter of type A and returns an instance of type C. Type B, being both the output for the 1st parameter and input for the 2nd one, serves as the knot between A and C.
The body of the function runs the result of lhs on rhs and returns. These functions are nested internally so that the function parameters, lhs and rhs, can be described as a sequence externally.

We could then do the following:

// Usage With Custom Operator

(half >>> square >>> increment >>> describe)(6) // "The resulting value is: 10"

This then becomes a better and more legible approach of describing a sequence of operations, where functions are chained instead of being nested.

Shout-out to Brandon Williams for showing me this stuff at Swift Summit 2017.
If you find this interesting, feel free to download this playground. Also take a look at this Wikipedia article on Function Composition.

📜 Rendering Markdown in Xcode 9

2017-09-19T20:54:06+00:00

Recently while exploring Apple’s new sample projects for iOS 11, I stumbled upon this sample ARKit project. Aside from the cool ARKit stuff going on, I saw how the README.md would actually get rendered.

This has been possible in Playgrounds for a while but never in an actual Xcode project, until now. This markdown rendition is different from the one advertised, where the Markdown is partially rendered and the syntax is included (see image below).

After some “extensive” research and excavation I found that .xcodesamplecode.plist is what triggers Xcode to render the Markdown as seen in their sample. This file can be found under the .xcodeproj (within Package Contents).

It seems Apple intended for Markdown files to be rendered only if they are under a sample project. Ideally there would be a way to toggle when it renders, similar to Playgrounds, but for now the simplest way is to drop the .xcodesamplecode.plist file under your .xcodeproj project. After dropping .xcodesamplecode.plist under the TestProject.xcodeproject I created it now renders the Markdown as expected. Download .xcodesamplecode.plist here.

TADA!!!

I think having renderable README.md files within Xcode could go a long way in helping make large projects easier to document and unpack, without the need to have external Markdown renderers. In addition to code comments this could greatly improve discoverability for new people coming into your project, as long as your project is well structured.