Swift嵌套可选值类型（结构体）属性修改的替代方案及选型咨询

Great question—this is one of the most common pain points when working with nested structs (value types) in Swift, especially when dealing with layers of optionals. Your current approach works, but it’s definitely not the only way. Let’s break down your options, along with the tradeoffs of each:

1. Encapsulate Modifications with mutating Methods #

This is the most idiomatic approach for value types. Instead of juggling optional bindings and copies at the call site, move the nested modification logic directly into your structs. This keeps your external code clean and centralizes logic where it belongs.

For example, you could add mutating functions to each level of your struct hierarchy:

struct CleaningDetail {
    var startTimes: [Date]?
    // Other properties...
}

struct CleaningsSchedule {
    var details: [CleaningDetail]?
    
    mutating func setEmptyStartTimes(forDetailAt index: Int) {
        guard var details = self.details, index < details.count else { return }
        var targetDetail = details[index]
        
        if targetDetail.startTimes == nil {
            targetDetail.startTimes = []
            details[index] = targetDetail
            self.details = details
        }
    }
}

struct Package {
    var cleaningsSchedule: CleaningsSchedule?
    
    mutating func setEmptyStartTimes(forDetailRow row: Int) {
        guard var schedule = self.cleaningsSchedule else { return }
        schedule.setEmptyStartTimes(forDetailAt: row)
        self.cleaningsSchedule = schedule
    }
}

Now your call site becomes dead simple:

initialPackage?.setEmptyStartTimes(forDetailRow: indexPath.row)

This keeps your business logic tied to the types that own the data, making your code easier to maintain and test.

2. Use a Custom with Helper for Mutable Copies #

If you don’t want to add a bunch of mutating methods for every possible modification, you can create a generic helper to simplify working with mutable copies of optional value types. This reduces the boilerplate of unwrapping, modifying, and reassigning:

extension Optional {
    mutating func with<T>(_ transform: (inout Wrapped) throws -> T) rethrows -> T? {
        guard var value = self else { return nil }
        let result = try transform(&value)
        self = value
        return result
    }
}

Then you can chain these calls to modify nested values without repeating optional checks:

initialPackage.with { package in
    package.cleaningsSchedule.with { schedule in
        schedule.details?.with { details in
            guard indexPath.row < details.count else { return }
            var detail = details[indexPath.row]
            if detail.startTimes == nil {
                detail.startTimes = []
                details[indexPath.row] = detail
            }
        }
    }
}

This is more flexible than mutating methods if you need to perform one-off or ad-hoc modifications.

3. Replace Structs with Classes (Reference Types) #

Whether this makes sense depends on your use case. Classes eliminate the need for copying because they’re reference types—you can modify nested properties directly once you’ve unwrapped the optional:

class CleaningDetail {
    var startTimes: [Date]?
    // Other properties...
}

// With classes, your original logic simplifies to:
if let detail = initialPackage?.cleaningsSchedule?.details?[indexPath.row], detail.startTimes == nil {
    detail.startTimes = []
}

That said, reference types trade simplicity for loss of value semantics. Value types (structs) give you thread safety by default, prevent unintended side effects (since modifications don’t affect other copies), and make it easier to track state changes. If your model is something you pass around, persist, or need to keep multiple versions of, structs are usually better. If your model is a single, long-lived object that’s modified in place across your app (like a view model for an ongoing edit session), classes might be more convenient.

4. Eliminate Optionals with Property Wrappers #

If nil vs. empty array doesn’t have distinct business meaning for startTimes, you can use a property wrapper to give it a default empty array, removing the optional entirely:

@propertyWrapper
struct DefaultEmptyArray<T> {
    var wrappedValue: [T]
    
    init() {
        wrappedValue = []
    }
    
    init(wrappedValue: [T]) {
        self.wrappedValue = wrappedValue
    }
}

struct CleaningDetail {
    @DefaultEmptyArray var startTimes: [Date]
    // Other properties...
}

Now you don’t need to check for nil at all—modifications become straightforward:

initialPackage?.cleaningsSchedule?.details?[indexPath.row].startTimes.append(Date())

This is a great option if your optional is just a convenience for "no items yet" rather than a distinct state.

Which Should You Choose? #

There’s no one-size-fits-all answer, but here’s a quick guide:

• Stick with structs if value semantics (safety, predictability) are important. Use mutating methods or the with helper to simplify modifications.
• Switch to classes only if your model’s primary purpose is to be a mutable, shared object where the overhead of copying structs becomes a real pain.
• Use property wrappers if you can eliminate optionals without changing your business logic.

内容的提问来源于stack exchange，提问作者Michał Ziobro