SE-0494: Add `isIdentical(to:)` Methods for Quick Comparisons to Concrete Types

[vanvoorden (Rick van Voorden)]

@CrystDragon

I find the second example in the motivation section (which uses SwiftUI) a little bit contrived. In either version of FavoriteContactList, we have this line private let contacts: [Contact]. And because Contact is a struct, we don't actually need favorites in the original code to be a computed property, neither for Storage.wrapped in the memorization-form code.

I think this example using SwiftUI should be updated to include some modification on contacts, otherwise it should be omitted entirely.

Presumably there would exist a view component in this app that performs some transformation on the source of truth. This could be a ContactDetailPage with a Form that gives users the option to Toggle the isFavorite property. But I wouldn't really see a lot of impact from actually writing out that component in the proposal. I think it's fine to wave the hands over that part.

I do want the SwiftUI example to remain in the proposal. But I wouldn't be totally opposed to adding one or two sentences here to say something along the lines of:

And another component in this application is updating these Contact values which then could lead to FavoriteContactList recomputing its favorites values.

But I definitely don't want to get all caught up in some "SwiftUI data flow" conversation here in this proposal where we start to debate Flux-Redux against MV*. I really don't think this proposal is the right time or place for any conversation about that. Hence my reluctance to actually show how these Contact values might be transformed.