[stdlib] add is identical methods to concrete types

[vanvoorden]

Many types in Standard Library are “copy-on-write” data structures. These types present as value types, but can leverage a reference to some shared state to optimize for performance. When we copy this value we copy a reference to shared storage. If we perform a mutation on a copy we can preserve value semantics by copying the storage reference to a unique value before we write our mutation: we “copy” on “write”.

This means that many types in Standard Library already have some private reference that can be checked in constant-time to determine if two values are identical. Because these types copy before writing, two values that are identical by their shared storage must be equal by value.

[vanvoorden]

@lorentey Here is my new attempt at a pitch only for identical functions on concrete types. My plan is to propose the update on Equatable in a separate pitch. Want to take a look and let me know what you think? How do you feel about being named as a coauthor? I expect to have enough time to complete all the implementations and unit tests myself and I do not need you to commit to allocating any engineering time.

I was planning to keep working on this over the next week and have it live on the forums 2025-06-16 after WWDC.

[lorentey]

This looks good! Thank you for pushing these. 👍🏼

We may need to subset out the Foundation APIs and run them through the evolution process specific to that project. Cc @parkera

[vanvoorden]

We may need to subset out the Foundation APIs and run them through the evolution process specific to that project.

Ahh… that makes sense. Keeping them together in one place would be nice… but I'm not opposed to breaking them apart.

[vanvoorden]

Does anyone have a very strong opinion on adding availability to a symbol on a type and the extension that declares that symbol?

[1] Like this:

extension String {
  @available(SwiftStdlib 6.3, *)
  public func isIdentical(to other: Self) -> Bool {
    self._guts.rawBits == other._guts.rawBits
  }
}

[2] Or this:

@available(SwiftStdlib 6.3, *)
extension String {
  @available(SwiftStdlib 6.3, *)
  public func isIdentical(to other: Self) -> Bool {
    self._guts.rawBits == other._guts.rawBits
  }
}

[3] Or this:

@available(SwiftStdlib 6.3, *)
extension String {
  public func isIdentical(to other: Self) -> Bool {
    self._guts.rawBits == other._guts.rawBits
  }
}

I'm generally seeing number [2] in std lib… but it also looks like I found [1] and [3] here and there… any strong opinions or consensus about that?

[vanvoorden]

https://github.com/swiftlang/swift/blob/swift-6.1.2-RELEASE/stdlib/public/core/Dictionary.swift#L1365-L1384

@lorentey Would you have any opinion about how impactful adding identity equality to Dictionary.Keys would be? It looks like as of right now the "fast path" in Keys is an identity check on the parent Dictionary. I'm guess we could just repurpose this as an identity check on Keys itself… but I'm also not really trying to keep increasing the scope of the proposal unless we think that data structure would end up being used this way. Any ideas about that?

[vanvoorden]

https://github.com/swiftlang/swift-evolution/blob/main/proposals/0376-function-back-deployment.md

@lorentey What would your thoughts be about shipping these functions as @backDeployed? Would you know if a decision like that must be documented in the proposal review itself… or can the proposal review remain agnostic over backdeployment and we save that conversation for the implementation diff reviews?

[vanvoorden]

@lorentey I tested all three diffs with local toolchain builds and ran some very basic soundness checks. I think this is ready to schedule for a proposal review.

[vanvoorden]

swiftlang/swift-foundation#1383

We are also discussing unifying the Foundation types back here for one proposal.

[vanvoorden]

@lorentey The new version of the proposal is a significant rewrite that I believe addresses many of the outstanding questions from reviewers so far:

• Motivation
  • Greatly expanded real-world examples. One command line utility and one SwiftUI app.
• Prior Art
  • Discussion of existing "fast path" value equality.
  • Discussion of existing alternatives to value equality:
    • withUnsafeBufferPointer
    • withUnsafeBytes and memcmp
    • Span
• Proposed Solution
  • Discussion of "abstract" axioms and principles
  • Discussion of types that are not Equatable
  • Application to previous real-world examples
• Detailed Design
  • All concrete types are presented
    • Header documentation comments include important axioms and principles
• Future Directions
  • Additional concrete types from Standard Library
    • Could ship in a follow up "second round" proposal
• Alternatives Considered
  • Exposing Identity
    • Discussion of why we do not want to escape identity
  • Different Names
    • Examples of different names suggested in pitch review
  • Generic Contexts
    • Discussion of why we are not proposing a protocol

I believe the major outstanding blockers from LSG left are:

• Determine what to do about String and Substring:
  • Should "summary bits" like the isASCII flag be included when we compare for identity equality?
• Determine what types must ship in this proposal?
  • What types from Future Directions must we include here in this "first round" proposal?

Please let me know if you have any more thoughts or ideas if you have time to read through this one. Thanks!