SE-240's CollectionDifference.Change

[xwu (Xiaodi Wu)]

@mpangburn

This type is rather unergonomic, as the associated values of each case are identical. Accessing the properties of a Change requires pattern matching, and not every associated value may be relevant.
The design is also problematic when iterating over the insertions: [Change] or removals: [Change] properties of CollectionDifference:

for insertion in diff.insertions {
    switch insertion {
        case .insert(offset: let offset, element: let element, associatedWith: let associatedOffset):
            /* highlight all inserted lines some color */
        case .remove(_, _, _):
            fatalError("Found a `remove` when iterating over insertions?")
}

The source even defines internal helper computed variables to avoid this.

I would suspect the rationale is similar to that of the core team in rejecting case accessors for Result:

Case accessors are a more complex question. The current proposal doesn't include case accessors, but the original proposal did, and we're anticipating a future proposal that will add automatic synthesis for case accessors. That synthesis will undoubtedly use names based on the actual case names, so at a first glance, it seems imprudent to use case names that we're not sure we'd want for the accessors. [...] More importantly, we don't want to burden this proposal because we haven't resolved those questions yet to our satisfaction.