Pocket Budget is about to grow a second kind of cost. Next to one-off expenses there are subscriptions, billed monthly or yearly. The summary screen shouldn’t care which is which: it needs a title and a monthly cost from each. Inheritance would force both into a class hierarchy. Swift’s answer is a protocol: a list of requirements any type can promise to meet, whether it’s a struct, a class or an enum.
\nimport Foundation\n\nprotocol BudgetItem {\n var title: String { get }\n var monthlyCost: Decimal { get }\n}{ get } means “readable”. A conforming type can satisfy it with a stored property or a computed one. Here are two conforming types, building on the Category enum from the previous lesson:
struct Expense: Identifiable, Hashable, BudgetItem {\n let id = UUID()\n var title: String\n var amount: Decimal\n var category: Category\n var date: Date\n\n var monthlyCost: Decimal { amount }\n}\n\nstruct Subscription: BudgetItem {\n var title: String\n var price: Decimal\n var billedYearly: Bool\n\n var monthlyCost: Decimal {\n billedYearly ? price / 12 : price\n }\n}Leave out monthlyCost and the compiler stops you with “type ‘Subscription’ does not conform to protocol ‘BudgetItem’”, and Xcode offers to add stubs for whatever is missing.
Expense also adopts two protocols from the standard library. Identifiable requires an id property, and SwiftUI’s List and ForEach use it to tell rows apart, so you’ll see it on nearly every model in this course. Hashable lets expenses go into a Set or be dictionary keys, and it includes Equatable, which gives you ==.
You didn’t write == or a hash function. For structs and enums, Swift synthesizes Equatable and Hashable when every stored property already conforms, and UUID, String, Decimal, Date and Category all do. Because id is part of that comparison, two expenses with identical titles and amounts are still different expenses, which is what the user means.
Every budget item needs a formatted price. Instead of writing it twice, extend the protocol:
\nextension BudgetItem {\n func formattedCost(currencyCode: String = \"USD\") -> String {\n monthlyCost.formatted(.currency(code: currencyCode))\n }\n}\n\nlet coffee = Expense(title: \"Coffee\", amount: 4.5, category: .food, date: .now)\nlet music = Subscription(title: \"Music\", price: 120, billedYearly: true)\n\ncoffee.formattedCost() // \"$4.50\"\nmusic.formattedCost(currencyCode: \"EUR\") // \"€10.00\"Every type that conforms to BudgetItem, now or in the future, gets formattedCost for free. This is the core of what people mean by protocol-oriented Swift: small protocols, with shared behaviour in extensions, adopted by value types.
Two keywords describe “a value of some type that conforms”:
\nlet items: [any BudgetItem] = [coffee, music]\nlet monthly = items.reduce(0) { $0 + $1.monthlyCost } // 14.5\n\nfunc cheapest(_ list: [some BudgetItem]) -> String? {\n list.min { $0.monthlyCost < $1.monthlyCost }?.title\n}any BudgetItem is a box that can hold a different conforming type in each slot, which is what a mixed list needs. some BudgetItem means “one specific conforming type, decided by the caller”: cheapest works with [Expense] or [Subscription], but not with a mix. Prefer some when it fits, because the compiler knows the exact type and can optimize. SwiftUI’s var body: some View uses the same keyword in return position, where the roles flip: the view’s implementation picks the one concrete type, and callers only know it’s a View.
Extensions aren’t limited to protocols. You can add computed properties, methods and conformances to any type, including Apple’s:
\nextension Decimal {\n var asCurrency: String { formatted(.currency(code: \"USD\")) }\n}\n\nextension Expense: CustomStringConvertible {\n var description: String { \"\\(title) (\\(category.rawValue)): \\(formattedCost())\" }\n}\n\nprint(coffee) // Coffee (food): $4.50Many Swift teams also use extensions to organise a file: the type’s stored properties at the top, then one extension per conformance. One limit applies everywhere: an extension can’t add stored properties, only computed ones. Also, when an extension method on a struct changes a property, it still needs mutating, exactly like a method in the original declaration.
Protocols are how Apple’s frameworks talk to your code. In SwiftUI, every screen you build is a struct that conforms to the View protocol, whose single requirement is a body property. List asks for Identifiable elements so it can track rows. Networking code asks for Codable so JSON can become your types. Swift 6 concurrency asks for Sendable before a value may cross between threads. Each time, the pattern is the one from this lesson: the framework states a contract, your type promises to meet it, and the compiler checks the promise.
You now have the full modelling toolkit: structs, classes, enums and protocols. The last piece before SwiftUI is what happens when an operation fails, such as an expense that would blow the budget, and how Swift’s error handling makes failure part of a function’s type.
\n","toc":[{"id":"sec-1","text":"Writing a protocol","level":2},{"id":"sec-2","text":"Standard protocols you’ll use every day","level":2},{"id":"sec-3","text":"Default behaviour with protocol extensions","level":2},{"id":"sec-4","text":"some and any","level":2},{"id":"sec-5","text":"Extending types you don’t own","level":2},{"id":"sec-6","text":"Where you’ll meet protocols next","level":2}],"takeaways":["A protocol lists requirements; any struct, class or enum that implements them can be used wherever the protocol is expected.","For structs and enums, Swift synthesizesEquatable and Hashable automatically when every stored property already conforms.","A protocol extension gives every conforming type a default implementation for free.","Extensions add methods, computed properties and conformances to any type, including ones from Apple, but never new stored properties.","some Protocol stands for one specific conforming type (for a parameter, the caller picks it); any Protocol is a box that can hold a different conforming type each time."],"further":[{"title":"Protocols","url":"https://docs.swift.org/swift-book/documentation/the-swift-programming-language/protocols/"},{"title":"Extensions","url":"https://docs.swift.org/swift-book/documentation/the-swift-programming-language/extensions/"},{"title":"Identifiable","url":"https://developer.apple.com/documentation/swift/identifiable"}],"quiz":[{"q":"struct Expense: Hashable has properties of type UUID, String and Decimal. What do you have to write to make it hashable?
== and hash(into:) because every property is already hashable.","why":"Correct. Synthesis covers structs and enums whose stored properties all conform."},{"text":"A hash(into:) method that combines each property by hand.","why":"You can, but only when you want different behaviour from the synthesized version."},{"text":"An extension Expense: Equatable with a custom ==.","why":"Hashable inherits from Equatable, and both are synthesized together."}],"answer":0},{"q":"Why can’t you add var note: String = "" to Decimal in an extension?
var asCurrency: String { … }."},{"text":"Decimal is a struct, and structs can’t be extended.","why":"Any type can be extended, including Apple’s structs."},{"text":"Extensions can’t add stored properties, because that would change the type’s memory layout.","why":"Correct. Add a computed property, or wrap the value in your own type."}],"answer":2},{"q":"You need one array holding both Expense and Subscription values, which both conform to BudgetItem. Which type do you declare?
[some BudgetItem]","why":"some means one concrete type for the whole array; it can’t mix expenses with subscriptions."},{"text":"[any BudgetItem]","why":"Correct. Each element is an existential box that can hold any conforming type."},{"text":"[BudgetItem.Type]","why":"That’s an array of types (metatypes), not of values."}],"answer":1},{"q":"A protocol extension defines formattedCost(). Subscription conforms but doesn’t implement it. What happens when you call music.formattedCost()?
Subscription is missing a requirement.","why":"A method supplied by a protocol extension is satisfied for every conforming type automatically."},{"text":"A runtime crash, because the method has no body in Subscription.","why":"The body lives in the extension, so there’s always something to run."},{"text":"The default implementation from the extension runs.","why":"Correct. That’s the purpose of a protocol extension: shared behaviour written once."}],"answer":2}],"exercise":{"kind":"spot-bug","language":"swift","code":"import Foundation\n\nstruct Budget {\n var limit: Decimal\n var spent: Decimal = 0\n}\n\nextension Budget: CustomStringConvertible {\n var remaining: Decimal { limit - spent }\n var description: String { \"\\(spent) of \\(limit) spent\" }\n\n func record(_ amount: Decimal) { spent += amount }\n}\n\nvar food = Budget(limit: 300)\nfood.record(42)\nprint(food)","bugLines":[12],"title":"The extension that won't compile","prompt":"A teammate moved Budget’s behaviour into an extension, and now the project doesn’t build. Select the line the compiler rejects.
Budget is a struct. Which line in the extension changes one of its stored properties?","Computed properties only read limit and spent. Look for an assignment.","Methods on structs that change self need a keyword in front of func."],"explanation":"Line 12 changes spent from a plain method, and struct methods can’t modify self unless they’re marked mutating. The compiler reports “left side of mutating operator isn’t mutable: ‘self’ is immutable”. Moving code into an extension doesn’t change the rules:
mutating func record(_ amount: Decimal) { spent += amount }The call site already uses var food, so it compiles once the method is mutating. With let food it would fail again, for the reason you saw in the structs lesson.