Swift Protocols Interview Questions

A Swift protocol is a blueprint of methods, properties, and other requirements that a conforming type (struct, class, or enum) implements. It is not a data structure, a memory-management construct, or a compiler directive. The other choices describe unrelated concepts: a Set is a collection type, ARC is the memory model, and attributes like @available are separate language features.

When a type conforms to more than one protocol, the protocol names are listed after the colon and separated by commas, e.g. struct Player: Movable, Drawable {}. The inheritance clause has no special operator for joining named protocols. The ampersand appears only in compound protocol types (such as Movable & Drawable used as a type), not in the conformance list.

The answer is protocol extensions. Writing a method body inside an extension of a protocol gives every conforming type a default implementation that it inherits without writing any code. A conforming type can still override that default with its own implementation. This is the core mechanism of protocol-oriented programming in Swift and is distinct from a bare protocol requirement, which every conforming type must implement itself.

Swift uses the protocol keyword to declare protocols, which are blueprints of methods, properties, and other requirements that conforming types adopt. Languages such as Java and C# use interface for a similar concept, but Swift's keyword is protocol.

The loop iterates over the list [1, 2, 3, 4, 5] and accumulates each value into total. The sum 1 + 2 + 3 + 4 + 5 equals 15, which is what print(total) outputs.

Swift lets you extend a protocol with default implementations using a protocol extension, written as extension SomeProtocol { … }, where you add the method or computed property. Any conforming type automatically inherits that implementation unless it provides its own, which is a core technique in protocol-oriented programming.

In Swift, protocol property requirements are always declared with var and must include either { get } (read-only) or { get set } (read-write). A { get } requirement only needs the property to be readable, so a conforming type can satisfy it with a let constant. A { get set } requirement demands settable access, which a let cannot provide. The option let count: Int is invalid protocol syntax because protocol requirements cannot use let, and var count: Int is invalid because it omits the mandatory { get } / { get set } clause.

In Swift, the associatedtype keyword declares a named placeholder type inside a protocol. The protocol body declares ContainerItem with associatedtype, and first() returns ContainerItem?. Each conforming type must then provide a concrete type for that name, either through an explicit typealias or by inference from its method signatures. This is the protocol-oriented counterpart of a generic type parameter, but it is resolved per conforming type rather than per call site. Note that typealias is not the answer here: it assigns a concrete type inside a conformer, while the protocol itself must use associatedtype to introduce the placeholder.

A single append is O(1) when the backing array has spare capacity. Only when the array is full is a larger array allocated and the existing elements copied, which is an O(n) operation for that one call. Because the capacity grows geometrically (by a constant factor greater than 1, commonly 2), resizes occur at exponentially spaced sizes, so the total copying over n appends is bounded by a geometric series, giving O(n) total work and therefore O(1) amortized per append. The expensive copies are spread across many cheap appends, so no single append is persistently expensive. The growth factor varies by implementation (CPython uses roughly 1.125), but any constant factor greater than 1 yields the same amortized bound.

The2 defining2 advantage of2 protocol-oriented2 programming in2 Swift2 is2 that2 protocols2 can2 be2 adopted by2 value2 types (structs2 and2 enums) and2 reference2 types (classes) alike, enabling2 shared2 abstractions and2 polymorphism across type2 kinds without2 being2 limited to a2 single class2 hierarchy. The2 claim about2 multiple2 inheritance of2 state2 is2 wrong because protocols2 cannot2 declare2 stored2 properties or2 state2 — they2 define2 requirements2 only. The2 claim that2 extension2 methods2 are2 always dynamically2 dispatched is2 wrong because methods2 defined only in2 a protocol2 extension2 (not2 declared as2 a requirement2) dispatch2 statically; only2 declared2 requirements2 use the2 witness2 table. The2 claim that2 default implementations2 are impossible is2 wrong because protocol2 extensions2 routinely2 provide2 them, allowing2 conforming2 types2 to2 inherit2 default2 behavior2.

A method declared inside the protocol body is a protocol requirement and gets a witness-table slot, so it dispatches dynamically when invoked through an existential. Methods defined only in a protocol extension are not requirements by default and therefore dispatch statically: the call resolves at compile time to the extension's implementation on the protocol type, rather than to the concrete conforming type's override.

A constrained protocol extension adds members to every conforming type only when the stated generic constraint holds. Here the constraint is on the associated type Element, so contains(_:) exists only for conformances where Element: Equatable. Conforming to Container does not depend on Element being Equatable; only the extra method is gated. Attempting to call contains(_:) on a container whose element type is not Equatable fails to compile, which is the guarantee the clause provides.

Methods declared only in a protocol extension are not protocol requirements, so they have no entry in the protocol witness table. When the call goes through an existential typed as Animal, Swift statically binds describe() to the extension's default implementation, which prints Animal: Dog. Requirements such as speak() are dispatched dynamically through the witness table, which is why they reach Dog's implementation. Declaring describe() in the protocol itself makes it a requirement, so the call dispatches dynamically to Dog.describe() and prints Dog.

The behavior depends on whether a method is a protocol requirement. describe() is defined only in an extension of Shape, so it is not a witness-table entry; a call through the existential Shape is resolved statically to the extension's default implementation, and Square's method is ignored. Declaring func describe() -> String in the protocol body makes it a requirement with a witness-table slot, so the call dispatches dynamically to Square's implementation and prints A square. The fix changes only the protocol declaration, not the conforming type.

value() is a requirement of the protocol, so p.value() on a P-typed existential is dispatched dynamically through the witness table to A's implementation, printing 3. derived() is not a requirement; it exists only in the protocol extension, so p.derived() is statically dispatched to the extension's version. Inside that version, self is typed P and value() is a requirement, so it dynamically dispatches to A.value() returning 3, and 3 * 7 = 21 is printed. a has the concrete type A, so a.value() calls A.value() (3) and a.derived() calls A's own derived() (55). The four lines are 3, 21, 3, 55.

The protocol Shape declares area() as a requirement but NOT perimeter() or describe() — those exist only in the protocol extension. When s (of existential type any Shape) calls describe(), the method is not in the witness table, so the compiler dispatches it statically against the static type Shape, selecting the extension's describe(). Inside that extension method, self.area() IS a protocol requirement, so it dispatches through the witness table to Square.area(), returning 2 * 2 = 4.0. However, self.perimeter() is NOT a protocol requirement, so it also dispatches statically to the extension's default perimeter(), returning 0.0. The Square-specific describe() and perimeter() are never reached because the static type is Shape, not Square. This is the core of protocol-oriented dispatch in Swift: only methods declared in the protocol body (requirements) get dynamic witness-table dispatch; extension-only methods are always statically dispatched.