Swift Opaque Type

Coder Orangu was confused about Swift’s jargons like Opaque Types, Existential Types ,and Type Erasure. After exploring these concepts, he comes here to simplify it for you. But first, let it ask you:

What is abstract coding?

Basics

Imagine stepping into a self-driving car. You enter your destination, sit back, and relax as the car drives. You have no idea how its engine works, how it avoids collision with other vehicles, or how it decides the best route. The car’s interface (a touch screen and a “Start” button) hides all the complexity, allowing you to enjoy your journey.

Similarly, hiding implementation details and providing a modular interface for developers to interact with is a core principle of coding.

Abstraction conveys the idea of what’s happening without explaining how.

A Protocol in Swift is an abstraction tool that separates the ideas about what a type does from the implementation details.

What Is an Opaque Type?

An opaque type refers to a value that conforms to a protocol without revealing the specific concrete type. The specific concrete type that is substituted is called the underlying type.

Opaque types are declared using the keyword some before a protocol. Opaque types can be used for inputs and outputs, meaning they can be declared as parameters or return types.

Opaque Type As Input & Output

Coder Orangu sometimes in the mood for bananas, other times peanuts, and occasionally a coconut. Let’s use Swift to model Orangu’s diet with protocols and opaque types.

protocol Food {
    var price: String { get }
    func eat() -> String
}

struct Banana: Food {
    var price: String = "1$"
    func eat() -> String { return "Peeling and eating a delicious banana!" }
}

struct Peanut: Food {
    var price: String = "5$"
    func eat() -> String { return "Cracking open some tasty peanuts!" }
}

struct Coconut: Food {
    var price: String = "10$"
    func eat() -> String { return "Breaking a coconut for a refreshing snack!" }
}

Opaque Type As Input

// Opaque type as input parameter
struct JungleCafe {    
    func menu(priceForFood food: some Food) -> String {
        return food.price
    }
}

Opaque Type As Output

func serveBreakfast() -> some Food {
    return Banana()
}

The underlying type of an opaque type must remain fixed within the variable’s scope; If you try to change it, the Swift compiler will get upset.

var breakfast: some Food = OranguCafe().serveBreakfast()
//No I want something else
breakfast = Coconut()

Cannot assign value of type ‘Coconut’ to type ‘some Food’.

Since a method can be called from anywhere in the source code, it cannot return different concrete types. For example, the following code will result in a compilation error:

func getFood(ofType type: String) -> some Food {
    if type == "Breakfast" {
        return Banana()
    } else if type == "Lunch"{
        return Peanut()
    } else {
        return Coconut()
    }
}

Function declares an opaque return type ‘some Food’, but the return statements in its body do not have matching underlying types.

This restriction ensures type safety and prevents mismatched types.

Type-Erased Container vs Opaque Type

After diving into the concept of opaque types, Coder Orangu wondered: that any also works with protocol conformance, why bother with opaque types?

Let’s break it down. A variable of type any Food can refer to any food that conforms to the protocol, and the compiler won’t complain.

var breakfast: any Food = Banana()
//Today Orangu is not in the mood to eat fruit.
breakfast = Coconut()

This happens because any completely erases type information. The concrete type is unknown at compile time and can be any type that conforms to the protocol.

any Ruins the Party!

Coder Orangu and friends arrive at the Jungle Café, before serving, the café staff (the compiler) wants to know each guest’s preference.

An associated type helps link each animal to its preferred food::

protocol PartyMember {
   associatedtype Food
    var preference: Food { get }
    func eat(_ food: Food) 
}

struct Monkey: PartyMember {
    var preference: Banana {
        Banana()
    }
    func eat(_ food: Banana) {
        print("Monkey is eating a banana!")
    }
}

struct Squirrel: PartyMember {
    var preference: Peanut {
        Peanut()
   }
    func eat(_ food: Peanut) {
        print("Squirrel is eating peanuts!")
    }
}

Now try this:

var animal: any PartyMember = Squirrel()
animal.eat(animal.preference)

An error will be reported by compiler that Member ‘eat’ cannot be used on value of type ‘any PartyMember’; consider using a generic constraint instead.

Why? Because any erased all type relationships, including associated types — now the compiler has no idea which type of food should be eaten.
To keep the associated type relationship intact, we should use some instead of any:

var animal: some PartyMember = Squirrel()
animal.eat(animal.preference)

When To Choose What:

    Use opaque types when you want to work with a specific concrete type but keep its details hidden.
    Use any when you need flexibility to handle multiple types conforming to the same protocol. For example, if the Cafe want to serve multiple foods to Orangu.

func serveAllFoods(foods: [any MonkeyFood]) {
    for food in foods {
        print(food.eat())
    }
}

Feature	any Protocol Conformance	some Protocol Conformance
Type Information	Erased (unknown at compile-time)	Hidden (known to the compiler)
Compile-Time Type Safety	No	Yes
Behavior Guarantee	Not guaranteed without constraints	Guaranteed by protocol conformance
Performance	Runtime overhead (type erasure, casting)	No runtime overhead (type known)
Consistency	Can handle multiple types	Refers to a single, fixed type

Conclusion

In general, use some by default, and switch to any only when you specifically need to store arbitrary values.

This approach ensures you only incur the cost of type erasure and its semantic limitations when the flexibility of storing multiple types is truly required.