Stylishly Swifty

Good talk and links here to keep you abreast of evolving Swift paradigms:

Swifty? Emerging patterns and idioms

Last Tuesday I gave a talk at Swift London called Swifty? looking at interesting patterns emerging from the community, as well as how Swift 3 will shape idiomatic code. You can see my slides on Speaker Deck.

The talk covered several topics, so I thought I’d link to some examples for those who want to learn more.

This is an even better post on namespacing:

Dear Erica: No-case Enums?

Dear Erica, Why would you create an enum with no cases?

This is such a great question! No-case enumerations represent a fairly obscure Swift “power tool”, and one that most developers are unaware of.

The answer, in a nutshell, is that they enable programmers to establish a mini-namespace with little overhead and an assurance that you can’t accidentally create type instances. Under their umbrella, you can group static members into namespaces, build singletons, create cohesive collections of functionality with a minimum surface eliminating freestanding functions, and in one outlier case provide services built around generic types…

And this is an interesting pattern for applying private type extensions which suits well our predisposition towards exposing only designated functionality, a position which is subject to some full and frank discourse over where they’re considering it as not just a style choice but an enforced language construct, if you’ve picked up on that brouhaha; if not, we’ll put an addendum here if/when something actionable happens. In the meantime, check out

Concealment design pattern in Swift

This article introduces a design pattern that I call Concealment, and demonstrates how to use the pattern in Swift code.


The Concealment pattern enables types to support novel, related functionality without adding nonessential members to their interface.


User-defined types can easily be overused in a codebase, giving more prominence to things than necessary. A common example is having a data model entity be involved with tangentially related concerns; such as validation checks, business rule processing, and display formatting. It is preferable to conceal the augmentation and usage of your types behind an API expressly built for a single responsibility, rather than expose those implementation details to all the types’ consumers…

Yep, we agree there; anything that reduces cognitive load is a Good Thing!


First Class Functions in Swift

10 Swift One Liners To Impress Your Friends

Enum Raw Values and Failable Initializers; Mixing Initializers

#257: Property Observers on Local Variables 🐤

How can I extend Array<MyStruct> with a custom function that should only work for these arrays?

Specifying function execution contexts

What are Protocols with Associated Types?; Type Erasure; Inception

Swift Type Aliases: Use Early and Often

#29 An alternative to if let and guard let

#32 Errorify String

Naming Things in Swift

Swift 3 Protocols

Refactoring to Clarity in Swift

Generic Protocols with Associated Type

Swift sequences: The art of being lazy

Swift Hashable

Bond: “A Swift binding framework” ; Bond Tutorial: Bindings in Swift

Express Yourself Swift Style

A Simple Undo/Redo Implementation in Swift

Loose coupling using default implementations in protocol extensions

SwiftTips: “A collection of Swift tips & tricks that I’ve shared on Twitter”

A Simple Undo/Redo Implementation in Swift

Using @autoclosure when designing Swift APIs

Working with text output streams

Statements, messages and reducers

Monadic Computation in Swift. Why?

Strongly typed identifiers in Swift

Identifying objects in Swift

Refactoring Reveals Truths

Chaining methods in swift — (Don’t confuse with optional chaining)

Lazy Cartesian Products in Swift

Alex | July 19, 2016

Leave a Reply