🎉 End-of-year Sale! Save 25% when you subscribe today.

The Many Faces of Flat‑Map: Part 2

Episode #43 • Jan 16, 2019 • Subscriber-Only

Now that we know that flatMap is important for flattening nested arrays and optionals, we should feel empowered to define it on our own types. This leads us to understanding its structure more in depth and how it’s different from map and zip.

Previous episode
The Many Faces of Flat‑Map: Part 2
Next episode
Locked

Unlock This Episode

Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.

Sign in with GitHub

Recap

We now know that flatMap is an important operation that solves a common problem. Important enough for Swift to provide this operation for arrays and optionals in the standard library.

However, all of the types we define for our own problems and applications, the ones that the Swift standard library knows nothing about, all have this nesting problem. The Result, Validated, Func, Parallel type and more. Can we define flatMap on them?

The answer is “yes we can and should be!” And as you define flatMap it uncovers interesting semantics of your types. It also will show interesting connections with zip, and that is what clarifies the purpose of the type. For example, why would you use Result over Validated? Why would you use Func over Parallel? It turns out that the way flatMap and zip relate to each other uncovers all of that.

So let’s define flatMap on our own types and see what it teaches us!

Flat‑map on Array and Optional


References

  • SE-0235: Add Result to the Standard Library
    Nov 7, 2018

    The Swift evolution review of the proposal to add a Result type to the standard library. It discussed many functional facets of the Result type, including which operators to include (including map and flatMap), and how they should be defined.

  • Railway Oriented Programming — error handling in functional languages
    Scott Wlaschin • Jun 4, 2014

    This talk explains a nice metaphor to understand how flatMap unlocks stateless error handling.

    Note

    When you build real world applications, you are not always on the “happy path”. You must deal with validation, logging, network and service errors, and other annoyances. How do you manage all this within a functional paradigm, when you can’t use exceptions, or do early returns, and when you have no stateful data?

    This talk will demonstrate a common approach to this challenge, using a fun and easy-to-understand “railway oriented programming” analogy. You’ll come away with insight into a powerful technique that handles errors in an elegant way using a simple, self-documenting design.

  • A Tale of Two Flat‑Maps
    Brandon Williams & Stephen Celis • Mar 27, 2018

    Up until Swift 4.1 there was an additional flatMap on sequences that we did not consider in this episode, but that’s because it doesn’t act quite like the normal flatMap. Swift ended up deprecating the overload, and we discuss why this happened in a previous episode:

    Note

    Swift 4.1 deprecated and renamed a particular overload of flatMap. What made this flatMap different from the others? We’ll explore this and how understanding that difference helps us explore generalizations of the operation to other structures and derive new, useful code!

Downloads

Get started with our free plan

Our free plan includes 1 subscriber-only episode of your choice, access to 64 free episodes with transcripts and code samples, and weekly updates from our newsletter.

View plans and pricing