Build the pieces of a tiny UI framework

It does not compile. Xcode reports

cannot assign value of type 'some Widget' (result of 'subtitle()') to type 'some Widget' (result of 'title()')

Only the first. The compiler's message names the problem exactly: the two values have different types, and it tells them apart by which function they came from. An opaque type is "the type title() returns". The fact that both happen to be Line is hidden from you on purpose, so that either function could change what it returns without breaking its callers.

At run time nothing is hidden: print(type(of: title()) == type(of: subtitle())) prints true. The distinction exists only for the compiler. This is why, in SwiftUI, two computed properties that both return some View cannot be used as the two sides of a ? :, even when you know they are the same view.

Where this comes from: SE-0244: Opaque Result Types · Hacking with Swift interview question: What are opaque return types? — SE-0244: “opaque result types are a different type for each function declaration”.

It does not compile. Xcode reports

cannot assign value of type 'Line' to type 'some Widget'

No — even though the new value is exactly the same type. Once you write some Widget, the code that follows is not allowed to know that the type is Line; all it knows is "one fixed type that is a Widget". So nothing can be shown to match it, apart from the variable's own value.

The lesson: some is for hiding a type from the users of an API. On a local variable it only takes information away from yourself. Write var badge = Line("NEW") and let the type be inferred.

Where this comes from: SE-0244: Opaque Result Types · The Swift book: Opaque and Boxed Protocol Types — The Swift book, “Opaque and Boxed Protocol Types”; SE-0328 extended where some may be written.

Run it. The console shows

Line Rule

It prints Line Rule. Each some Widget in a parameter list is its own generic parameter, so the two arguments are free to be different types: the function above is short for func stack<A: Widget, B: Widget>(_ top: A, _ bottom: B).

The version with a single W says something stricter — both arguments must be the same type — and with a Line and a Rule it does not compile: conflicting arguments to generic parameter 'W' ('Line' vs. 'Rule') So some in a parameter is not always a drop-in replacement for a named generic. When two values must share a type, you still need the name.

Where this comes from: SE-0341: Opaque parameter declarations · WWDC22: Embrace Swift generics — SE-0341, “Opaque parameter declarations”.

Run it. The console shows

16 40
40
40

40 bytes, always — whatever is inside. An any Widget is a fixed-size box: room for three machine words of value (24 bytes), plus a pointer to the value's type and a pointer to the table of its Widget methods. A Line fits in the 24 bytes. A Big does not, so Swift allocates it on the heap and stores a pointer.

That is the price of any: possibly an allocation, and every method call looked up through the table while the program runs. With some or a generic, the compiler knows the real type, stores the value directly, and can call — even inline — the method itself. It is the performance half of why SwiftUI is built on some View.

Where this comes from: WWDC16: Understanding Swift Performance (2016 — still the reference on how existentials are stored) · WWDC22: Embrace Swift generics · Hacking with Swift interview question: What is type erasure and when would you use it? — WWDC16 “Understanding Swift Performance” is still the reference for how existential containers are laid out.

Run it. The console shows

Line
Array<Widget>

Line, then Array<Widget>. When you pass an any Widget to a generic function, Swift opens the box for the length of that call: inside show, the parameter really is a Line. This is what lets existential and generic code work together.

But the type cannot escape. twice returns [W], and outside the call there is no name for W — so the result is erased again, to an array of any Widget. (That is what the second line shows; Swift prints the box type as plain Widget.) And when the opened type would have to become part of another type you are constructing, as in Bordered(widget) in the tutorial, there is nothing to erase to, and it does not compile.

Where this comes from: SE-0352: Implicitly opened existentials — SE-0352, “Implicitly opened existentials” (Swift 5.7).

It does not compile. Xcode reports

type 'any Shape' cannot conform to 'Equatable'

The first. Since Swift 5.7 any protocol can be used as any P, even one with Self or associated-type requirements, and you may use every member that does not depend on knowing the concrete type. area is one of those.

== is not. Equatable compares two values of the same type, and two boxes might hold different shapes, so the compiler cannot offer it. To compare them you have to open one and cast the other — or avoid the question by keeping the concrete type with generics. It is the reason you cannot write [any Equatable] and call == on its elements, and the reason SwiftUI asks for Hashable values through generics rather than boxes.

Where this comes from: SE-0309: Unlock existentials for all protocols · SE-0335: Introduce existential any — SE-0309, “Unlock existentials for all protocols”.

False, as of Swift 6.4. The code above was compiled in the Swift 6 language mode and was accepted without a word. SE-0335, which introduced any, said a missing any would become an error "in Swift 6 or a later language mode". It turned out to be later: the rule is an opt-in feature named ExistentialAny.

With that feature switched on, the same code gets: use of protocol 'Widget' as a type must be written 'any Widget'; this will be an error in a future Swift language mode So write any everywhere — it is clearer, and one day it will be required — but do not tell an interviewer that Swift 6 enforces it. Plenty of articles written in 2022 and 2023 still say so.

Where this comes from: SE-0335: Introduce existential any — SE-0335, “Transitioning to any”.

It does not compile. Xcode reports

result values in '? :' expression have mismatching types 'Text' and 'Image'

No. A ? : is a single expression, and a single expression has a single type. Text and Image are two.

The if/else form works for a different reason from the one people assume. body is a result-builder block, and inside a builder an if/else is turned into one value of the type _ConditionalContent<Text, Image> — your Either from the tutorial. Keep the ternary for choosing between two values of the same type, such as .foregroundStyle(big ? .red : .blue). That form has an advantage you will meet in lesson 7: it leaves the view's identity alone.

Where this comes from: SE-0244: Opaque Result Types · ViewBuilder · Senior iOS Interview Preparation (GitHub) — The interview-preparation repository lists it under view identity: “if/else vs modifier”.

It does not compile. Xcode reports

type 'ContentView' does not conform to protocol 'View'

No. The View protocol requires body to have one concrete type that is itself a View. any View is a box, and the box does not conform to View — the same thing you saw in the tutorial with Bordered(badge(isNew: true)).

This is why SwiftUI has AnyView: a real struct that conforms to View and hides another view inside itself. Reach for it last. The usual ways to return "different views" are an if/else or switch in a builder, or @ViewBuilder on a helper — both keep the types visible to SwiftUI.

Where this comes from: Hacking with Swift interview question: What is type erasure and when would you use it? · ViewBuilder — Hacking with Swift lists “What is type erasure and when would you use it?” among its interview questions.