[SE-0494][StdLib] Add isTriviallyIdentical(to:) Methods to String and Substring

[vanvoorden]

Background

SE-0494

We propose new isTriviallyIdentical(to:) instance methods to the following concrete types for determining in constant-time if two instances must be equal by-value:

• String
• Substring
• Array
• ArraySlice
• ContiguousArray
• Dictionary
• Set

Instead of “one big diff”… we can try and keep the diffs grouped together by similar functionality:

• String, Substring
• Array, ArraySlice, ContiguousArray
• Dictionary, Set

Changes

String

We already expose a public-but-underscored method on String to return identity equality.¹ We can add a new public-and-supported method:

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

What happens to the existing underscored method?

• Delete it?
• Deprecate it?
• Leave it?

For now… we don't need to have a strong opinion about the underscored method. The underscored method is alwaysEmitIntoClient and already deploys back to earlier releases. Deleting the underscored method would then mean a breaking change for apps that already depend on the underscored method.

Substring

We do not currently expose identity equality on Substring. We can follow a similar pattern to String:

extension Substring {
  @available(SwiftStdlib 6.3, *)
  public func isTriviallyIdentical(to other: Self) -> Bool {
    self._wholeGuts.rawBits == other._wholeGuts.rawBits &&
    self._offsetRange == other._offsetRange
  }
}

Test Plan

New tests were added for String and Substring.

Benchmarks

New benchmarks were added for String and Substring.

Footnotes

1. https://github.com/swiftlang/swift/blob/swift-6.1.2-RELEASE/stdlib/public/core/String.swift#L397-L415 ↩

[vanvoorden]

@lorentey No big rush… but if you had any advice about these implementations that would be a big help. I'm planning to post another pitch to swift forums on monday. It's just a pitch thread… so it's not blocked on implementation diffs.

I would expect at least one more week before I would have some more implementations for the rest of the types to unblock a proposal review thread.

[lorentey]

(In hindsight, we should've proposed adding the same methods to [Sub]String.UnicodeScalarView as well -- the scalar views are supposed to be fully formed string types. Oh well, there is always tomorrow!)

[vanvoorden]

(In hindsight, we should've proposed adding the same methods to [Sub]String.UnicodeScalarView as well -- the scalar views are supposed to be fully formed string types. Oh well, there is always tomorrow!)

https://github.com/swiftlang/swift-evolution/blob/main/proposals/0494-add-is-identical-methods.md#detailed-design

@lorentey No… we did actually add UnicodeScalarView to the proposal. That's been accepted.

[vanvoorden]

@lorentey I think this is the right way to guard from benchmarks… and then we have to go in and change this after 6.3 goes live to prod?

[Azoy]

No, we have SwiftStdlib 6.3 that you should use instead.

[vanvoorden]

@Azoy I'm pretty sure I tried that before… but SwiftStdlib 6.3 was not available from benchmarks. Was there a recent change to support that?

[vanvoorden]

@swift-ci Please smoke test

[vanvoorden]

@swift-ci Please smoke test

[vanvoorden]

@swift-ci Please smoke test

[vanvoorden]

@lorentey Something that's not totally clear to me is when new test cases should go under test or under validation-test… any ideas?