[Pitch #2] Add `isIdentical` Methods for Quick Comparisons to Concrete Types

[vanvoorden (Rick van Voorden)]

@John_McCall

I know the isIdentical name has precedent from Span, but I'm a little concerned about it. There are a lot of languages where equality checks are done with a method call, including Java (equals) and Objective-C (isEqualTo:).[1] My concern is that someone coming to Swift from one of these languages might look for a method named something like that and find isIdentical(to:), making it an attractive nuisance. I think it would be better if the method had a more specific name that talked about the representation of the value, like hasSameRepresentation(as:).

Our "prior art" in this space goes back years… well before Span was built:

@lorentey

For a number of years we've already been using the isIdentical(to:) name for exactly this purpose, including in stdlib internals and in public API inside packages like swift-collections. It seems like as straightforward/boring/obvious a name as they come -- I don't remember anyone misunderstanding it to mean anything other than what it is.

I certainly think you are entitled to your own opinion on what the name should be… but I would then ask you for the data to back up this opinion. What prior art would support this opinion as being more correct?

I do think it's fine (and encouraged) for reviewers to tell me what their opinion might be… but the current opinion in this proposal comes with several documented instances of prior art backing up our claim that:

• yes this is the correct name
• product engineers are not going to be confused

Explaining what your opinion might be is a good first step… but then I would like for the persuasion to begin. Please persuade me why this new opinion is more correct than my current opinion taking into account the years worth of prior art we have documented.

If the new opinion does not have data backing it up… it's trending in the direction of conjecture. Conjecture is not necessarily bad… and if two conjectures are battling it out head to head maybe then we can discuss more of the "what ifs" and "might happens". But if our existing opinion documents all this prior art I think that presents a much stronger argument.