Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.
Previously on Point-Free we spent several episodes exploring the topic of randomness. It’s a topic that seems at odds with functional programming. We like to work with functions that take data in and spit data out in a consistent fashion, but randomness is all about inconsistency!
Despite this seemingly irreconcilable difference, we found that a randomness API deeply benefited from functional programming principles, specifically composition. We were able to distill the idea of randomness into a single type that could be transformed and combined using familiar functional concepts, and we ended up with a little library that was much more flexible and extensible than the randomness APIs that ship with Swift.
But even though we built this library around functional principles, it’s far from functional. We’d be remiss to ignore the fact that it’s completely unpredictable and untestable, and any code that uses it becomes immediately unpredictable and untestable as a result! One of the things we value in functional programming is the ability to reason about our code using predictable units that can be easily tested, so today we’re going to do something about it: we’re going to make the untestable testable.
This Swift Evolution proposal to create a unified random API, and a secure random API for all platforms, was accepted and implemented in Swift 4.2.
Gen type made its first appearance in this episode bridging function composition with randomness.
Randomness is a topic that may not seem so functional, but it gives us a wonderful opportunity to explore composition. After a survey of what randomness looks like in Swift today, we’ll build a complex set of random APIs from just a single unit.
We first introduced the
Environment concept for controlling dependencies in this episode.
Today we’re going to control the world! Well, dependencies to the outside world, at least. We’ll define the “dependency injection” problem and show a lightweight solution that can be implemented in your code base with little work and no third party library.
Swift 5.0 finally introduced the
Result type to the standard library, and with it a patch that conforms
Error to itself, allowing Result’s
Failure parameter to be constrained to
Error in an ergonomic fashion. While this conformance is a special case, Swift may automatically conform certain protocols to themselves in the future.
This blog post explores the need for
AnySequence in Swift as a pattern for working around some of the shortcomings of protocols in Swift.
This edition of Friday Q&A shows how type erasure can manifest itself in many different ways. While you can wrap the functionality of a protocol in a concrete data type, as we explored in our series on protocol witnesses, you can also use subclasses and plain ole functions.