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

[vanvoorden (Rick van Voorden)]

@allevato

@vanvoorden

My general advice for engineers would be to discourage a "strong" mental coupling between a representation being identical and a representation having identity.

If this is the kind of connection you want to discourage, choosing a name that doesn't share the same root would perhaps achieve that better than offering the discouragement as a rule-of-thumb after the fact?

For better or for worse… we already sort of "soft-overload" the concept of identity:

@Karl

The thing is, there are lots of kinds of identity. The thing I think we're talking about here is "record identity" - i.e. that two objects may have different values and not be substitutable, but conceptually both talk about the same element of data, like the primary-key in a database. Another kind of identity is object/reference identity.

The name "Identifiable" doesn't really make clear what kind of identity is being talked about, and the default implementation for classes confuses the two concepts. Even for classes, they might not be the same.

I didn't really start working with Swift until after SE-0261 already shipped. In hindsight… I believe engineers would probably wish we would have named this protocol something like IdentifierProviding. But it is what it is and we are where we are.

I could make the argument that plenty of engineers understand that Identifiable is not appropriate for comparing the identity of value types and LSG could make the argument that plenty of engineers still to this day do not understand that Identifiable is not appropriate for comparing the identity of value types. Is it confusing? Or is it not confusing? I guess it depends who you ask…

I don't know if there's one right answer here. There is precedent IMO that we can ship an API named "identical" and this can be decoupled from whether or not a value type has an identity. Whether or not the learned experience from shipping Identifiable is a Good Thing or a Bad Thing might not have an easy answer.

It's possible the overwhelming consensus across LSG is that our "original sin" comes from Identifiable. This is where we began to soft-overload the concept of identity outside of ObjectIdentifier and this is the road we don't want to continue going down. That would then make sense that LSG would push back on isIdentical(to:). This proposal could claim SE-0261 as a "prior art"… but LSG could then claim it was a flawed and imperfect prior art to begin with.