Nothingness has been a regular topic of discussion on NSHipster, from our first article about nil in Objective-C to our recent look at the Never type in Swift. But today’s article is perhaps the most fraught with horror vacui of them all, as we gaze now into the Void of Swift.
Void? In Swift, it’s nothing but an empty tuple.
We become aware of the
Void as we fill it.
Void values have no members: no methods, no values, not even a name. It’s a something more nothing than
nil. For an empty vessel, Xcode gives us nothing more than empty advice.
Perhaps the most prominent and curious use of the
Void type in the standard library is found in the
Types conforming to
ExpressibleByNilLiteral can be initialized with the
nil literal. Most types don’t adopt this protocol, as it makes more sense to represent the absence of a specified value using an
Optional for that type. But you may encounter it occasionally.
The required initializer for
ExpressibleByNilLiteral shouldn’t take any real argument. (If it did, what would that even be?) However, the requirement can’t just be an empty initializer
init() — that’s already used as the default initializer for many types.
You could try to work around this by changing the requirement to a type method that returned a
nil instance, but some mandatory internal state may be inaccessible outside of an initializer. But a better solution — and the one used here — is to add a
nilLiterallabel by way of a
Void argument. It’s an ingenious use of existing functionality to achieve unconventional results.
Tuples, along with metatypes (like
Int.Type, the result of calling
Int.self), function types (like
(String) -> Bool) and existentials (like
Encodable & Decodable), comprise non-nominal types. In contrast to the nominal, or named, types that comprise most of Swift, non-nominal types are defined in relation to other types.
Non-nominal types cannot be extended.
Void is an empty tuple, and because tuples are non-nominal types, you can’t add methods or properties or conformance to protocols.
Void doesn’t conform to
Equatable — it simply can’t. Yet when we invoke the “is equal to” operator (
==), it works as expected.
We reconcile this apparent contradiction with a global free-function, declared outside of any formal protocol.
This same treatment is given to the “is less than” operator (
<), which acts as a stand-in for the
Comparable protocol and its derived comparison operators.
The Swift standard library provides implementations of the comparison functions for tuples with arity, or size, up to 6. This is, however, considered a hack. At various times, the Swift core team has expressed interest in adding formal
Equatable conformance for tuples, but at the time of writing, no formal proposals are being discussed.
Void, as a non-nominal type, can’t be extended. However,
Void is still a type, and can, therefore, be used as a generic constraint.
For example, consider this generic container for a single value:
We can first take advantage of conditional conformance, arguably the killer feature in Swift 4.1, to extend
Wrapper to adopt
Equatable when it wraps a value that is itself
Using the same trick from before, we can approximate
Equatable behavior by implementing a top-level
== function that takes
In doing so, we can now successfully compare two constructed wrappers around
However, if we attempt to assign such a wrapped value to a variable, the compiler generates a mysterious error.
The horror of the
Void becomes once again its own inverted retort.
Even when you dare not speak its non-nominal name, there is no escaping
Any function declaration with no explicit return value implicitly returns
This behavior is curious, but not particularly useful, and the compiler will generate a warning if you attempt to assign a variable to the result of a function that returns
You can silence this warning by explicitly specifying the
By contrast, functions that return non-
Void values generate warnings if you don’t assign their return value.
For more details, see SE-0047 “Defaulting non-Void functions so they warn on unused results”.
If you squint at
Void? long enough, you might start to mistake it for
Bool. These types are isometric, both having exactly two states:
But isometry doesn’t imply equivalence. The most glaring difference between the two is that
Void isn’t — and can’t be, for the same reasons that it’s not
Equatable. So you can’t do this:
Void may be the spookiest type in Swift, but
Bool gives it a run for its money when typealias’d to
Void? can act in the same way as
Bool. Consider the following function that randomly throws an error:
The correct way to use this method is to call it within a
do / catch block using a
The incorrect-but-ostensibly-valid way to do this would be to exploit the fact that
failsRandomly() implicitly returns
try? expression transforms the result of a statement that throws into an optional value, which in the case of
failsRandomly(), results in
.some value (that is,
!= nil), that means the method returned without throwing an error. If
nil, then we know that the method produced an error.
As much as you may dislike the ceremony of
do / catch blocks, you have to admit that they’re a lot prettier than what’s happening here.
It’s a stretch, but this approach might be valid in very particular and peculiar situations. For example, you might use a static property on a class to lazily produce some kind of side effect exactly once using a self-evaluating closure:
Even still, an
Bool value would probably be more appropriate.
If, while reading this chilling account you start to shiver, you can channel the necrotic energy of the
Void type to conjure immense amounts of heat to warm your spirits.
…which is to say, the following code causes
lldb-rpc-server to max out your CPU:
Keeping in the Lovecraft-ian tradition,
Void has a physical form that the computer is incapable of processing; simply witnessing it renders the process incurably insane.
Let’s conclude our hallowed study of
Void with a familiar refrain.
If you recall our article about the
Never type, a
Result type with its
Error type set to
Never can be used to represent operations that always succeed.
In a similar way, we might use
Void as the
Value type to represent operations that, when they succeed, don’t produce any meaningful result.
For example, apps may implement tell-tale heartbeat by regularly “pinging” a server with a simple network request.
According to HTTP semantics, the correct status code for a hypothetical
/ping endpoint would be 204 No Content.
In the completion handler of the request, success would be indicated by the following call:
Not enamored with effusive parentheticals (but why not?), you could make thing a bit nicer through a strategic extension on
Nothing lost; nothing gained.
Though it may seem like a purely academic exercise — philosophical, even. But an investigation into the
Void yields deep insights into the very fabric of reality for the Swift programming language.
In ancient times, long before Swift had seen the light of day, tuples played a fundamental role in the language. They represented argument lists and associated enumeration values, fluidly moving between its different contexts. At some point that model broke down. And the language has yet to reconcile the incongruities between these disparate constructs.
So according to Swift Mythos,
Void would be the paragon of the elder gods: the true singleton, blind nullary at the center of infinity unaware of its role or influence; the compiler unable to behold it.
But perhaps this is all just an invention at the periphery of our understanding — a manifestation of our misgivings about the long-term viability of the language. After all, when you stare into the
Void stares back into you.