Existential types (any keyword) in Swift

Introduction

Existential types let you work with values of any type that follow a certain rule or protocol. The any keyword makes it clear you want to use a value that can be any type matching that rule.

When you want to store different types that share the same behavior in one place.

When you want to pass a value to a function but don't care about its exact type, only that it follows a protocol.

When you want to write flexible code that works with many types without knowing them all in advance.

Syntax

Swift

let variableName: any ProtocolName

The any keyword explicitly marks a type as existential, meaning it can hold any value conforming to the protocol.

Before Swift 5.7, existential types were implicit, but now any is required for clarity.

Examples

This declares a variable shape that can hold any value that follows the Drawable protocol.

Swift

protocol Drawable {
    func draw()
}

let shape: any Drawable

This function accepts any value that can describe itself as a string, using the any keyword to mark the parameter type.

Swift

func printDescription(_ item: any CustomStringConvertible) {
    print(item.description)
}

An array holding different types that all conform to Equatable, using any to allow mixed types.

Swift

var items: [any Equatable] = [5, "hello", 3.14]

Sample Program

This program defines a protocol Greetable and two types that follow it: Person and Robot. The function sayHello takes any Greetable value using the any keyword and calls its greet() method. It then prints greetings from both a person and a robot.

Swift

protocol Greetable {
    func greet() -> String
}

struct Person: Greetable {
    var name: String
    func greet() -> String {
        return "Hello, \(name)!"
    }
}

struct Robot: Greetable {
    func greet() -> String {
        return "Beep boop."
    }
}

func sayHello(to entity: any Greetable) {
    print(entity.greet())
}

let alice = Person(name: "Alice")
let bot = Robot()

sayHello(to: alice)
sayHello(to: bot)

Important Notes

Using any makes your code clearer about when you are working with existential types.

Existential types can have some performance cost compared to concrete types because Swift uses dynamic dispatch.

You cannot use protocol methods that require Self or associated types directly with existential types without extra work.

Summary

any marks a type as existential, meaning it can hold any value conforming to a protocol.

Use existential types to write flexible code that works with many types sharing behavior.

Existential types improve code clarity and safety by making type flexibility explicit.

Practice

1. What does the any keyword indicate in Swift when used with a protocol type?

easy

A. It creates a new protocol that inherits from the original.

B. It marks the type as existential, allowing any value conforming to the protocol.

C. It restricts the type to only one specific conforming type.

D. It converts the protocol into a concrete class.

Solution

1. Step 1: Understand the role of any in Swift

   The any keyword is used to mark a type as existential, meaning it can hold any value that conforms to a given protocol.

2. Step 2: Compare with other options

   The incorrect options describe behaviors unrelated to any. It does not create new protocols, restrict to one type, or convert protocols to classes.

3. Final Answer:

   It marks the type as existential, allowing any value conforming to the protocol. -> Option B

4. Quick Check:

   any means existential type [OK]

Hint: Remember: any means 'any conforming type' [OK]

Common Mistakes:

• Thinking any creates a new protocol
• Confusing any with type restriction
• Assuming any converts protocols to classes

2. Which of the following is the correct syntax to declare a variable that can hold any value conforming to the protocol Drawable using existential types?

easy

A. var shape: Drawable

B. var shape: Drawable & any

C. var shape: any Drawable

D. var shape: Drawable<any>

Solution

1. Step 1: Recall the syntax for existential types

   In Swift, to declare a variable that can hold any value conforming to a protocol, you use any ProtocolName. So here, it is any Drawable.

2. Step 2: Analyze each option

   var shape: Drawable misses any, so it is not explicit existential. var shape: Drawable & any and var shape: Drawable<any> have incorrect syntax. Only var shape: any Drawable uses the correct syntax.

3. Final Answer:

   var shape: any Drawable -> Option C

4. Quick Check:

   Existential syntax = any Protocol [OK]

Hint: Use any before protocol name for existential types [OK]

Common Mistakes:

• Omitting any keyword
• Placing any after protocol name
• Using angle brackets incorrectly

3. What will be the output of the following Swift code?

protocol Greetable {
    func greet() -> String
}

struct Person: Greetable {
    func greet() -> String { "Hello" }
}

let greeter: any Greetable = Person()
print(greeter.greet())

medium

A. Hello

B. Error: Protocol method not implemented

C. Runtime error

D. nil

Solution

1. Step 1: Understand the protocol and struct

   The protocol Greetable requires a greet() method returning a String. The struct Person implements this method returning "Hello".

2. Step 2: Analyze the existential usage and output

   The variable greeter is declared as any Greetable and assigned a Person instance. Calling greeter.greet() calls the implemented method and returns "Hello".

3. Final Answer:

   Hello -> Option A

4. Quick Check:

   Existential calls implemented method = "Hello" [OK]

Hint: Existential calls protocol methods on conforming instance [OK]

Common Mistakes:

• Expecting a compile or runtime error
• Thinking protocol methods are not accessible
• Assuming nil is returned

4. Identify the error in the following Swift code using existential types and fix it:

protocol Runnable {
    func run()
}

struct Dog: Runnable {
    func run() { print("Dog runs") }
}

var runner: Runnable = Dog()
runner.run()

medium

A. Missing any keyword before Runnable in variable declaration.

B. Dog does not conform to Runnable protocol.

C. run() method should return a value.

D. Variable runner should be a constant (let) instead of var.

Solution

1. Step 1: Check variable declaration syntax

   Since Swift 5.7, existential types require the any keyword explicitly. The declaration var runner: Runnable is invalid; it should be var runner: any Runnable.

2. Step 2: Verify other parts

   Dog conforms correctly, run() returns Void (allowed), and var is allowed. So only missing any is the error.

3. Final Answer:

   Missing any keyword before Runnable in variable declaration. -> Option A

4. Quick Check:

   Existential types need any keyword [OK]

Hint: Add any before protocol for existential variables [OK]

Common Mistakes:

• Omitting any keyword
• Thinking protocol conformance is missing
• Expecting run() to return a value

5. You want to write a function that accepts any value conforming to the Codable protocol and returns its JSON string representation. Which is the correct way to declare the function parameter using existential types?

hard

A. func encodeToJSON(value: Codable & any) -> String

B. func encodeToJSON(value: Codable) -> String

C. func encodeToJSON(value: T) -> String

D. func encodeToJSON(value: any Codable) -> String

Solution

1. Step 1: Understand existential vs generic parameters

   Using any Codable declares an existential type parameter that can accept any value conforming to Codable. This matches the question requirement.

2. Step 2: Analyze each option

   func encodeToJSON(value: Codable) -> String omits any, which is invalid syntax for existential types. func encodeToJSON(value: T) -> String uses generics, which is valid but not existential. func encodeToJSON(value: Codable & any) -> String has incorrect syntax. func encodeToJSON(value: any Codable) -> String is correct.

3. Final Answer:

   func encodeToJSON(value: any Codable) -> String -> Option D

4. Quick Check:

   Existential parameter syntax = any Protocol [OK]

Hint: Use any before protocol for existential function parameters [OK]

Common Mistakes:

• Using generics instead of existential types
• Omitting any keyword
• Incorrect syntax with & or angle brackets