lambda swift logo

lambda swift

Swift Language Fundamentals

Swift is a modern programming language that balances powerful features with safety. To build our shopping app from first principles, we must first understand Swift’s fundamental building blocks. In this chapter, we dive into the core language concepts: basic data types, algebraic data types (structs, enums, and classes), and functions (including currying and inout mechanics). We’ll implement a simplified integer type to see how Swift’s standard library defines basic types from the ground up.

Basic Types, Constants, and Variables

Swift is a statically typed language, meaning each variable or constant has a type known at compile time. The simplest types are the primitive types – numbers, Booleans, characters – which form the basic values your code manipulates. In Swift, you create constants with let (immutable bindings) and variables with var (mutable bindings). For example:

let maximumItems = 100     // constant of type Int
var currentItemCount = 0   // variable of type Int
currentItemCount = 42      // OK to mutate a var
// maximumItems = 50       // Error: cannot assign to let constant

Here, maximumItems is a constant integer and cannot be changed once set, whereas currentItemCount is a variable that can change over time. Swift’s type inference deduces that both are Int from the literal values, but you can also annotate types explicitly if needed (e.g., let maximumItems: Int = 100). Using let wherever possible is a Swift best practice, as it makes data immutable by default and thus safer.

Numeric and Boolean Types

Swift provides a family of integer types: Int (the default, with platform-specific size such as 64-bit on modern systems), and fixed-size variants like Int8, Int16, Int32, Int64 (and their unsigned counterparts UInt8, UInt16, etc.). It also has floating-point types Float (32-bit) and Double (64-bit), and a Bool type for Boolean values (true or false). These types may feel “primitive,” but under the hood Swift implements them as structs in the standard library. In fact, even types like Int and Double are essentially just structs with special lower-level support. This means they behave as value types (more on value semantics soon). For example, an Int in Swift’s standard library is defined roughly as:

public struct Int: FixedWidthInteger, SignedInteger {
  // ...
  // internally stores an integer value of machine word size
  // and provides methods and operators
}

Swift’s Bool is similarly defined as a struct that can only be true or false. Because these fundamental types are value types, assigning and passing them around creates copies rather than references. For instance:

var x = 10
var y = x    // y gets a copy of x’s value (10)
y = 20       // changing y doesn’t affect x
print(x)     // still 10

This copy-on-assignment behavior is guaranteed for value types, ensuring that x and y above are independent. (In contrast, for reference types like classes, assignment would copy a reference/pointer, leading x and y to refer to the same object — we’ll discuss this difference later.)

Why value types? One big advantage of value types is predictability. Because each copy is independent, you avoid unintended side effects from elsewhere in your program. No other part of your code can unexpectedly change a let constant or a separate copy of a struct. As the Swift documentation puts it: “One advantage of using value types is that you can be certain no other place in your program can affect the value. You can reason about the code in front of you without needing to know what else is happening elsewhere.”. This property is invaluable for writing robust code, and it’s a reason we will lean toward structs and enums for most data modeling.

Algebraic Data Types: Structs, Enums, and Classes

Beyond primitives, Swift lets you define your own data types. In fact, Swift’s type system supports algebraic data types (ADTs) – a term from type theory describing composite types formed by combining other types. There are two fundamental ways to combine types:

  • Product types: combine multiple pieces of data (think “AND” – the type includes this and that). In Swift, structures (structs) and tuples are product types.
  • Sum types: represent a choice between types (think “OR” – the value is either this or that). In Swift, enumerations (enums) are sum types.

Swift’s classes can also be seen as product types (they have multiple properties like a struct does), but with reference semantics and additional capabilities like inheritance. Let’s look at each in turn.

Product Types (Structs)

A product type’s value consists of all of its constituent values. If you have a struct with two fields, you need both fields to fully describe a value of that struct. Mathematically, if type A has N possible values and type B has M possible values, a product type (A, B) has N×M possible combinations (hence the name “product”). For example:

struct ShoppingItem {
  let name: String
  let quantity: Int
  let purchased: Bool
}

Here ShoppingItem is a struct with three properties. An instance of ShoppingItem contains a name, a quantity, and a purchased flag. All three pieces together define an item. If name can be, say, any string, quantity any integer, and purchased either true/false, the number of possible ShoppingItem values is the product of the possibilities of each field.

In practical terms, to create a ShoppingItem you must provide all the fields, for example:

let milk = ShoppingItem(name: "Milk", quantity: 2, purchased: false)

This is a straightforward way to bundle related data. Structs can have methods and computed properties too, but fundamentally they are containers for data. Swift structs are value types, meaning they are copied on assignment or when passed to functions. This value semantics is great for our app’s state management: if we model state as structs, each modification can produce a new state value, avoiding unintended mutations of old state.

Note on classes vs structs: Classes in Swift are similar to structs in that they can have properties and methods, but classes are reference types. If ShoppingItem were a class and you assigned an instance to a new variable, both variables would refer to the same object. With a struct, each assignment creates an independent copy. The choice between structs and classes often comes down to whether you want value semantics (no unexpected sharing) or reference semantics (shared, mutable object). In this book and in SwiftUI architecture in general, we emphasize value types for state and data models, to make reasoning about data flow easier (no aliasing issues).

Sum Types (Enums)

A sum type value is one of several alternatives. Swift’s enum allows you to define a type that can take on different forms (cases), each possibly with associated values. The number of possible values of an enum is the sum of the possibilities of each case. As an illustration, consider a simple enum for an app section:

enum AppSection {
  case shoppingList
  case recipes
  case events
  case reminders
  case newsFeed
}

AppSection can be either .shoppingList or .recipes or .events, etc. Each instance of AppSection is exactly one of those cases. If we have 5 cases here, there are 5 possible values of AppSection (hence sum type – conceptually 1+1+1+1+1 possibilities). Enums become more powerful when cases carry associated data:

enum LoadingState {
  case idle
  case loading
  case loaded(ShoppingList)
  case failed(Error)
}

This enum has four cases, two of which carry additional information (the ShoppingList that was loaded or the Error returned). A value of LoadingState might be, for example, .loading or .loaded(ShoppingList(items: []). In either case, it’s one or the other (loading vs loaded), never both at the same time. Enums with associated values let us model data that has variants with different content, while still being type-safe. To use such an enum, we typically use a switch statement to handle each case:

@ViewBuilder
func display(loadingState: LoadingState) -> some View {
  switch item {
    case .idle: 
    Button("Load Shopping List", action: model.loadShoppingList)

    case .loading:
    ProgressView()

    case .loaded(let shoppingList):
    ShoppingListView(shoppingList: shoppingList)

    case .failed(let error):
    ErrorMessageView(error: error)
  }
}

This exhaustiveness (the compiler forces us to cover all cases) is a boon for reliability – if we add a new case to the enum later, the compiler will show errors in any switch that hasn’t handled the new case, prompting us to update our logic.

A common enum in Swift is the Optional type, defined roughly as:

enum Optional<Wrapped> {
  case none
  case some(Wrapped)
}

Optional<T> is a sum type with two possibilities: either no value (.none) or “some” value of type T. This is used throughout Swift for values that might be absent (nil). It’s a great example of how a sum type can increase safety by making the absence of a value an explicit state that must be handled.

In summary, structs (and classes/tuples) are product types – they hold a fixed set of values all together – whereas enums are sum types – they indicate which variant of several possibilities a value is. In our app, we might use structs to model things like a Recipe or an Event (with many properties), and enums to model things like a form of user input or an app state that can be one of several modes.

Value Types vs Reference Types

Before moving on, let’s underscore the value vs reference distinction, since it’s central to Swift’s design:

  • Value types: Each instance keeps a unique copy of its data. Assigning or passing it around creates a copy. Examples: structs, enums, tuples, and all the basic types (Int, Bool, etc.). Value types give you local reasoning — you know that no other code can modify your instance unless you explicitly pass it and get a modified copy back.
  • Reference types: Instances are heap-allocated and variables store a reference (pointer) to the data. Assigning one variable to another doesn’t copy the data, but rather creates a new reference to the same object. Examples: classes, actor types, and closures. References allow shared mutable state, which can be useful but also requires caution to avoid unintended side effects or race conditions.

We will lean toward value types for most data modeling due to the safety of not sharing mutable state. Our app’s data (shopping lists, recipes, etc.) will primarily be represented with structs and enums. Always consider: Does this piece of data represent a thing with an identity that should be shared (use a class), or is it just a bundle of data (use a struct)? Given SwiftUI’s unidirectional data flow, using value types for state will simplify the logic of updates.

Functions and Methods

Functions are the basic building blocks of behavior in Swift. Swift treats functions as first-class citizens, meaning functions are values too – you can assign a function to a variable, pass it as an argument, or even return it from other functions. This enables a functional programming style where you can manipulate functions similar to data.

Defining and Using Functions

A function in Swift is defined with the func keyword, a name, parameter list, and return type (if it returns a value). For example:

func add(_ a: Int, _ b: Int) -> Int {
  return a + b
}

This add function takes two Int values and returns their sum as an Int. We can call add(2, 3) to get 5. The underscore in the parameter list (_ a: Int, _ b: Int) means we can call it without external parameter names (so it’s called as add(2,3) rather than add(a:2, b:3)). Swift allows both styles of naming parameters for clarity at call site, but here we opted for none for brevity.

Crucially, we can treat add as a value. For instance:

let operation: (Int, Int) -> Int = add    // assign function to a variable
print(operation(4, 5)) // prints 9

The type of operation is (Int, Int) -> Int, meaning “a function that takes two Ints and returns an Int.” We assigned it to the add function. Now operation(4,5) calls add internally. This showcases that functions in Swift can be stored in variables or constants just like integers or strings can.

Functions that operate on or produce other functions are called higher-order functions. For example, Swift’s standard library defines higher-order methods like Array.map, which takes a function as input to transform array elements. We could write a higher-order function ourselves. Suppose we want a function that given an Int increment value, returns a new function that adds that increment to any Int:

func makeAdder(for increment: Int) -> (Int) -> Int {
  func adder(x: Int) -> Int {
​    return x + increment
  }
  return adder
}

let add5 = makeAdder(for: 5)
print(add5(10)) // 15, (10 + 5)

let add10 = makeAdder(for: 10)
print(add10(10)) // 20, (10 + 10)

Here, makeAdder is a function that returns another function. Calling makeAdder(for: 5) gives us a function back (we stored it in add5) that itself takes an Int and adds 5 to it. This may seem mind-bending at first, but it’s a powerful pattern for creating configurable behavior.

Currying and Partial Application

In functional programming, currying is the technique of transforming a function that takes multiple arguments into a chain of functions each taking a single argument. For instance, consider a function of two parameters (Int, Double) -> String. Currying conceptually turns this into (Int) -> (Double) -> String – i.e., a function that takes an Int and returns another function that takes a Double and finally returns a String. The idea is that you can call the function in stages: give it the first argument, get back a function waiting for the second argument, then supply the second. This allows partial application – you can “fix” some arguments early and get a function back that you can use later.

Swift’s syntax doesn’t automatically curry every function, but you can achieve currying by writing functions that return other functions (like makeAdder above). Moreover, instance methods in Swift have a curried nature when you treat them as function values. An instance method (a function inside a struct/class) can be referenced in a curried form: it’s essentially a function that takes the instance as the first argument and the method’s parameters as the subsequent arguments. In other words, an instance method in Swift is really just a curried function under the hood — the instance is an implicit first parameter.

For example, suppose we have a struct with an instance method:

struct Greeter {
  func greet(_ name: String) -> String {
​    return "Hello, \(name)!"
  }
}

We can use the method in two ways: the normal way, by calling it on an instance, or the curried way:

let greeter = Greeter()
let message = greeter.greet("Swift")  // "Hello, Swift!"

// Curried usage:

let greeterFunc = Greeter.greet    // function reference, type: (Greeter) -> (String) -> String

let greeterWithInstance = greeterFunc(greeter) // this binds the instance, now type: (String) -> String

print(greeterWithInstance("World"))  // "Hello, World!"

In the curried usage, Greeter.greet is a function of type (Greeter) -> (String) -> String. When we call greeterFunc(greeter), we get back a (String) -> String function bound to that specific greeter. Calling that with "World" produces the greeting. This example illustrates the concept that methods are not magical – they’re functions that get the instance passed in automatically when you call via dot-syntax. Understanding this can help in advanced scenarios, like when you pass instance methods as callbacks.

While currying isn’t commonly used in everyday Swift code, recognizing functions as first-class and the curried nature of methods can lead to elegant solutions (for example, using MyType.myMethod as a callback that later needs an instance provided).

inout Parameters and Mutation

Sometimes you want a function to modify one of its arguments. In Swift, you can mark a parameter with the keyword inout to indicate it is passed by reference (sort of). An inout parameter allows the function to alter the value, and have that change reflected back to the caller. For example:

func increment(_ value: inout Int) {
  value += 1
}

var count = 10

increment(&count)

print(count) // 11, the original variable was incremented

Here, increment takes an inout Int. We call it with &count to pass a reference to count. Inside the function, value += 1 actually mutates the original count. But it’s important to know how this works under the hood: Swift’s inout is implemented as copy-in, copy-out semantics. When you call a function with an inout argument, Swift copies the argument’s value, gives the function that copy to work with (and in case of a struct, it might even operate on the original in place for optimization, but conceptually it’s a separate copy). Then when the function returns, the copy’s value is written back to the original variable. It’s as if the function had returned a new value and we did count = <new value>.

Because of this, you can think of an inout function as a function that takes a value and returns a new value (of the same type) – the syntax just makes it look like in-place mutation. For instance, the increment function above could be reimagined (not in actual syntax, but in concept) as:

func incrementValue(_ value: Int) -> Int {
  return value + 1
}

count = incrementValue(count)

Both approaches end up with count being incremented. The inout form is sometimes more convenient when you want to modify multiple variables or when mutating a complex struct in place. But it does not break the safety of value types because the mutation is local to the function and then the result is assigned back. “inout is short for copy-in copy-out. It's as if the variable is read once (copied out), and then written back after.” (Inout behavious - Using Swift - Swift Forums). This behavior is why a property observer (didSet) will fire when you pass a property as inout — Swift writes the value back even if the function didn’t change it, to maintain consistency.

One related concept is mutating methods on value types. In a struct, if you mark a method as mutating, that method can modify (self or its properties) in place. Under the hood, a mutating method is doing the same thing as an inout: it’s allowed to change the instance, and after the method call, the modified instance is written back to the caller. For example:

struct Counter {
  var count: Int

  mutating func increment() {
​    count += 1  // this actually mutates self.count
  }
}

var counter = Counter(count: 0)

counter.increment()

print(counter.count) // 1

If Counter were a class, increment wouldn’t need mutating (classes can always mutate their own properties, since they are reference types). But for a struct, mutating is required because you’re changing a value type in place. Conceptually, it’s like the method returns a new version of the struct and Swift replaces the old one with it. This design keeps value types safe and predictable: you opt-in to in-place modification with mutating/inout, otherwise all functions on a struct just read values and return new values without side effects.

Implementing a Basic Int Type from Scratch

To truly understand Swift’s approach to data types, it’s insightful to recreate a simplified version of a basic type. The Int type in Swift is part of the standard library, implemented as a struct that conforms to a host of integer protocols for arithmetic and binary operations. While the real implementation uses some compiler magic for efficiency, we can sketch out our own basic integer type to see the principles in action.

Let’s create a toy 8-bit integer type (for simplicity) called TinyInt. This will behave like a small integer that can wrap around from 0 to 255 (similar to an unsigned 8-bit int). We’ll use Swift’s existing UInt8 as the storage (to avoid dealing with raw bits ourselves, since UInt8 is readily available and also 0...255):

struct TinyInt: Equatable {
  private var _value: UInt8  // underlying storage, 0 to 255

  init(_ value: UInt8) {
​    _value = value
  }

  func adding(_ other: TinyInt) -> TinyInt {
​    // add with wraparound
​    let (sum, _) = _value.addingReportingOverflow(other._value)
​    return TinyInt(sum)
  }

  // Equatable conformance (== operator) comes for free from compiler if all members are Equatable
}

This is a very minimal integer type. It stores an 8-bit value. We provided an initializer and a method adding to add two TinyInt values. We took advantage of Swift’s built-in addingReportingOverflow on UInt8 which returns a tuple of (result, didOverflow). We ignore overflow flag for now and just wrap (this matches how Swift’s default unsigned integers operate with wraparound on overflow if using &+ operators, though normally Swift’s + would trap on overflow for signed integers).

We can use TinyInt like:

let a = TinyInt(250)
let b = TinyInt(10)
let c = a.adding(b)

print(c)  // TinyInt(_value: 4) because 250 + 10 = 260, wraps to 4 in 8 bits

Of course, real Swift Int is much more powerful. It supports negative values (ours doesn’t), a far larger range (at least 64-bit), and conforms to protocols like AdditiveArithmetic, BinaryInteger, CustomStringConvertible for printing, etc. In the actual Swift standard library, Int is defined as a struct with a single stored property of a built-in word-sized integer type (on 64-bit platforms, that’s 64 bits) (How does Swift implement primitive types in its standard library? : r/ProgrammingLanguages). The implementation uses a code generation technique (via a .gyb template) to create all the standard integer types (Int8, Int16, …, UInt64, Int) from a generic blueprint. But fundamentally, each of those is a struct with an underlying primitive (Builtin.Intx) and a bunch of operations defined. One excerpt from a discussion of Swift’s implementation states: “Int is a regular struct with a single stored property of type Builtin.Word. But the latter is a magical compiler built-in.” (How does Swift implement primitive types in its standard library? : r/ProgrammingLanguages) – meaning the only special sauce is that storage type which the compiler knows how to manipulate at a low level.

To mirror a bit of what Int does, we could add more functionality to TinyInt. For instance, implement addition via the + operator by overloading, and maybe support subtraction:

extension TinyInt {

  static func + (lhs: TinyInt, rhs: TinyInt) -> TinyInt {
​    return lhs.adding(rhs)
  }

  static func - (lhs: TinyInt, rhs: TinyInt) -> TinyInt {
​    let (diff, _) = lhs._value.subtractingReportingOverflow(rhs._value)
​    return TinyInt(diff)
  }

}

This allows let x = a + b if a and b are TinyInt. We could also implement CustomStringConvertible to print it nicely, etc. The point is that there’s nothing fundamentally different between how we define TinyInt and how Swift defines Int – aside from lots of optimizations and protocol conformances in the real thing. Indeed these basic types are “just like any other struct” a Swift programmer could write, aside from the use of some built-in operations.

By implementing a tiny integer, we see the power of Swift’s system: we can extend it with new value types that behave like built-in types. We could, for example, make a big integer type or a fraction type by using structs, and hook into operators and protocols to use them naturally in code. Swift’s protocol-oriented design is on full display with Int: it conforms to FixedWidthInteger, SignedInteger, Numeric, CustomStringConvertible, and more. If one were to implement a full custom Int, one would need to conform to those protocols to integrate with the language features (like literal convertible, arithmetic operators, etc.). For our TinyInt, we kept it simple, but we did implicitly conform to Equatable (the compiler can synthesize == for structs whose members are Equatable).

Takeaway: Understanding how a type like Int can be a value type with an underlying representation and a bunch of methods/operators helps reinforce the concept of value semantics. When you use numbers in Swift, you’re dealing with value types, which is why something like:

func double(_ x: Int) -> Int { 
  var result = x
  result *= 2

  return result
}

doesn’t change the original Int passed in – x was copied into the function. This is the same for any struct. Our upcoming app will leverage this heavily: data will flow through functions and views and often be copied, not shared, which avoids many classes of bugs.

Conclusion

We revisited Swift’s core language principles from the ground up. We covered how basic types and constants/variables work, emphasizing immutability and value semantics. We explored algebraic data types – structs (product types) and enums (sum types) – and touched on classes, solidifying why value types are preferred for most modeling. We dug into functions as first-class entities, seeing how Swift enables a functional style with higher-order functions and even how methods are essentially curried functions. We also clarified how inout and mutating operations allow controlled mutation in a value-semantics world. Finally, we built a tiny integer type, gaining insight into how something as fundamental as Int is put together in Swift.

← What makes a SwiftUI app?