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

[vanvoorden (Rick van Voorden)]

@tera

My only (and minor) concern is that the name isIdentical(to:) is not scary enough. In that regard isKnownIdentical(to:) following the example of isKnownUniquelyReferenced & co could be an option.

I'm actually sort of still "saving" isKnownIdentical(to:) for the future proposal that puts this directly on Equatable:

[Pitch #2] Add `isKnownIdentical` Method for Quick Comparisons to `Equatable`

Hi! Here is a new pitch refined from an earlier one: Add isKnownIdentical Method for Quick Comparisons to Equatable Proposal: SE-NNNN Authors: Rick van Voorden, Karoy Lorentey Review Manager: TBD Status: Awaiting implementation Implementation: TODO Review: (Pre-Pitch), (Pitch #1) Introduction We propose a new isKnownIdentical method to Equatable for determining in constant-time if two instances must be equal by-value. Motivation Suppose we have some code that listens to elements from an As…

TBF… that's not to say that a proposal that isn't even on the calendar for review — and which LSG has explicitly declined to review — would be the only reason to block this proposal from using that name.

Looking at this — or any other debates about different names — keeps coming back to one important detail that none of the reviewers proposing these different names have done a good job addressing: the prior art.

I'm not just some guy standing at the bus stop on Homestead and Wolfe yelling at you about why isIdentical(to:) is the right name. I'm some guy standing at the bus stop on Homestead and Wolfe yelling at you about why isIdentical(to:) is the right name with data to back me up on that.

Some examples of the data and evidence I can bring to the table:

• Standard Library has shipped an unsupported-underscored public implementation of isIdentical(to:) on String for years.
• Collections has shipped supported public implementations of isIdentical(to:) on concrete types like BigString and Rope for years.
• Standard Library shipped a supported public implementation of isIdentical(to:) on Span.
  • The SE-0447 proposal review came with zero requests to change the name of isIdentical(to:).

I don't want to discourage any engineers from posting here with suggestions for different names. I encourage engineers to post here with suggestions for different names and I will act in good faith to consider alternatives. That does not mean I'm going to make it easy for anyone to change my opinion about this. Disregarding the years of prior art telling us isIdentical(to:) is the right name — without any clear agreement why it should be disregarded — would be an example of me making it easy to change my opinion.

What I really want to see is for any engineer that disagrees with us naming this method isIdentical(to:) to please address the prior art in this space:

• Why is this prior art "wrong"? Why does the existence of this prior art not imply that isIdentical(to:) is the right name?
  • If an engineer proposes a different name for isIdentical(to:) on the concrete types in this proposal, does that same engineer also propose we go back and change isIdentical(to:) everywhere it's already being used for this purpose?
  • Where was this feedback when Span was being reviewed? Why did no engineer come forward during proposal review and request to change the name of isIdentical(to:)?
• What prior art supports a different name for isIdentical(to:)?
  • Where in Standard Library do we use that different name for the operation we are proposing here?
  • Where in adjacent Swift libraries do we use that different name for the operation we are proposing here?
  • Where in other languages or ecosystems do we use that different name for the operation we are proposing here?