A “Type Erasure” Pattern that Works in Swift

Introduction

If you have ever tried to use Swift protocols with associated types as types, you probably had (just like me) a very rough first (and possibly second) ride.  Things that should be intuitively doable are just not and the compiler gives infuriating error messages.  It comes down to the fact that the language is not yet “finished” (and, as a result, protocols are not really usable as types — yet).  The good news is that problems have workarounds and one such workaround is “type erasure” (not the Java compiler feature, something else that goes by the same name).  Apple uses the type erasure pattern every time you read Any<Something> and cleverer people than myself described it well (more information in the references at the end).  This is my attempt at understanding the pattern.

So what’s the problem?

Imagine that you have a protocol Cup  that describes a generic cup, with an associated type Content  that describes the cup’s content.  Imagine that this protocol has some methods and some properties.  For fun (and for realism) let’s make these methods mutating  and returning and instance of Self  (the specific instance of Cup we are dealing with).

Let’s define some concrete types for Content .

Let’s also add some concrete types for the protocol Cup . A cup of tea and a cup of coffee perhaps.  Honouring the spirit of Swift, I’ll make them value types ( struct ) but it would work in the same way for a class , without any further adjustment.

We can nicely create different instances of cups with different contents.

And here are the problems that I invariably face when I start thinking of Cup  as a type (it’s not a type! It’s a protocol!).

(1) Collection of protocol types

(2) Returning a protocol type in a function

(3) Taking a protocol type as a parameter  to a function

(4) Using a protocol type as a type for class or struct properties

The error message

The error message, in all cases above, is always the same: protocol ‘Cup’ can only be used as a generic constraint because it has Self or associated type requirements.  In other words, if a protocol has associated types you cannot use such protocol as a type. It makes sense, the Swift compiler will not know what exact protocol type you are dealing with unless the associated type is specified.  A nice mnemonic way to put could be:

Swift does not like multidimensional type uncertainty, but one dimensional type uncertainty is OK.

If we can somehow fix the associated type Content , we can make it work.  There are individual workarounds that work for problems (2) to (4) but they have different limitations: we are not going to discuss them here.  We are going to present a more general solution that takes care of all four problems.

The Solution

The architecture for the solution requires a few steps and a lot of patience to follow.  I will try my best to be clear.  Here we go.

(1) Base class mocking the protocol

First let’s define a base class that describes the protocol Cup .  The associated type Content  is now turned into a generic parameter for the class.  The class cannot be used directly because it cannot be initialised.  Furthermore, every property and every method throw a fatal error upon access or call: they must be overridden, all of them.  Why do we need this base class?  It’s a trick.  As we will see later, we need to be able to store a subclass of it but we cannot refer directly to an instance of such subclass.

(2) A box containing a concrete instance of the protocol

Let’s define a box, where the concrete type for protocol Cup  is stored: such box will inherit from our previously define abstract class.  By inheriting from _AnyBase , it also follows the Cup  protocol.  The generic parameter ConcreteCup  also follows the protocol Cup .  All methods and properties of ConcreteCup  are wrapped by this class. Note that when referring to this class we need to specify a concrete type for Cup . For example: _AnyCupBox<TeaCup> .  That is not what we want.  When referring to its super class instead, we only need to specify a concrete type for its Content .  For example: _AnyCupBase<Tea> .  This should shed some light on why we need a base abstract class to inherit from and this trick lays at the heart of the technique.

(3) The pseudo-protocol

And finally we can define the public class that we are going to use.

See how this works!

Conclusion

While I am still not very comfortable with this pattern (a lot of boilerplate, difficult to fully grasp), I will give it a go as it seems very general.   You can also refer to two other excellent blog posts by Realm and by The Big Nerd Ranch basically outlining the same architecture and source of inspiration for this writing.

Leave a Reply