This episode is for subscribers only. To access it, and all past and future episodes, become a subscriber today!See subscription optionsorLog in
Sign up for our weekly newsletter to be notified of new episodes, and unlock access to any subscriber-only episode of your choosing!Sign up for free episode
It’s time to ask “what’s the point?” and “what’s the point is three-fold. We are going to discuss three important aspects in having a deep understanding of
We are going to show that
flatMap form a kind of functional, domain-specific language for modeling pipelines of data. And seeing a usage of one of these operators we will already have a strong intuition for what that line of code could possibly be doing, without even knowing too much about the types involved.
Once we see that we will have convinced ourselves that these operations have a very well-defined signature, and we shouldn’t be smudging it in order to suite our needs. Sometimes we’ll have a function signature that looks kinda like
flatMap but it isn’t quite and we’ll want to call it
flatMap for ease. We want to make the case that everything we have learned shows us that is the wrong decision, and our APIs will be better off if we do not do that.
And then finally, we begin to ask ourselves very complex questions about how all of these operators interact with each other. These are problems that we feel would have been intractable if we didn’t already have a solid foundation of understand the purpose of
flatMap, and we would have had a very difficult time coming up with any concise, clear answers.
The meanings behind the signatures of
flatMap are very concise, and describe very well what their purpose is. This intuition is so strong that we can be presented with a whole new type that we are not familiar with and be told it has a
map operation and instantly know that means we can unwrap the type, apply a transformation and wrap it back up. Or be told that it has a
zip operation and so that we can take a bunch of values, independently run their computations, and obtain a new, single value from the type. Or be told that it has a
flatMap operation, and now you know you can can sequence these values together so that one follows another.
So, let’s look at what power this gives us by looking at some interesting uses of these operators on some concrete types:
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
flatMap), and how they should be defined.
This talk explains a nice metaphor to understand how
flatMap unlocks stateless error handling.
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.
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:
Swift 4.1 deprecated and renamed a particular overload of
flatMap. What made this
flatMapdifferent 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!