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

[vanvoorden (Rick van Voorden)]

@John_McCall

We think that the concrete implementations should document that values produced by copying the same value, with no intervening mutations, will compare identical.

I actually had some questions about that and started this side discussion:

What is a "copy"?

It might sound like an "easy" answer… but I am struggling to find where the definition of this might be documented. For example: This tells me that a type which is Copyable is a type that can be copied… but then what does that mean? There might be some more clues in SE-0390: All currently existing types in Swift are copyable, meaning it is possible to create multiple identical, interchangeable representations of any value of the type. But then what does that mean? Are "identical" and "i…

The implication seems to be that if we consider SE-0390 to be the "canon" definition of "what is a copy" then we already have the implication that a copy is identical.

I was considering collecting some thoughts from that thread and then writing an "appendix" on the proposal as an attempt to connect the dots between "copies" and representations that are "identical-indistinguishable" and "interchangeable-substitutable"… but I'm not sure I have enough context to try and answer some of the ambiguity there once and for all.

Could you please confirm if the feedback to update the proposal and explicitly confirm that a copy must be identical was directed at the "abstract" section where we attempted to generalize isIdentical(to:) or to the "concrete" sections where we wrote out header documentation for every concrete type being presented? Nevermind… I did not read correctly. The feedback was to update the header doc comments on the concrete types. SGTM.

@John_McCall

Otherwise we don't think it's necessary to document the behavior of details like the string summary bits, beyond saying that equal values produced in other ways may or may not compare identical. [emphasis added]

I believe we already do document that currently for every concrete type:

  /// string storage object. Therefore, identical strings are guaranteed to
  /// compare equal with `==`, but not all equal strings are considered
  /// identical.

So I think this already covered the request that we confirm that equal values do not imply identical values. Would you be able to confirm if LSG was looking for extra documentation for that on top of what was already being proposed?

@John_McCall

We would like at least the String view types to be included in the proposal.

Just to help me confirm… are we talking about:

• String.UnicodeScalarView
• String.UTF16View
• String.UTF8View
• Substring.UnicodeScalarView
• Substring.UTF16View
• Substring.UTF8View

The String views plus the Substring views? Is that correct?

My plan would be to just copy over the header doc comments from String and Substring for these new concrete types. But if anyone thinks of some kind of weird gotchas here that could impact the proposed semantics then please let me know and we can think through that together.

@John_McCall

However, as an exception to the general rule requiring implementations, we are comfortable with not implementing isIdentical for these types before the proposal goes to review. Furthermore, you don't need to be on the hook to implement them in any case; other maintainers will just make sure they're implemented before the feature is released.

That's a big help for me and I appreciate the extra flexibility on that. Thanks!