[RFC][DNM] Add isIdentical
Methods for Quick Comparisons to String and Substring
#82055
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
swiftlang/swift-evolution#2875
We propose new
isIdentical
instance methods to the following concrete types for determining in constant-time if two instances must be equal by-value:Instead of “one big diff”… we can try and keep the diffs grouped together by similar functionality:
Let’s start with a diff to add
isIdentical
toString
andSubstring
. These types share some implementation details that might not apply toArray
orDictionary
, but we might also see some general patterns and opinions that we want to influence the remaining implementation diffs.Changes
String
We already expose a public-but-underscored method on
String
to return identity equality.1 We can add a new public-and-supported method:And just call the existing underscored method.
What happens to the existing underscored method?
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 unless we then back-deploy the newisIdentical
method.These implementation diffs will unblock a formal proposal review. My understanding is we don't need to block a proposal review on deciding the fate of the underscored method or a strategy about back-deployment on the new method. We can keep that conversation going and either update this diff with a new strategy on back-deployment or land some cleanup in a follow up diff before the next branch cut.
Substring
We do not currently expose identity equality on
Substring
. We can follow a similar pattern toString
:We can add a public-but-underscored method that back-deploys and a public-and-supported method that calls the underscored method.
If we decide to go with a different strategy with
String
to remove or deprecate the existing underscored method we can also decide not to ship an underscored method onSubstring
.Test Plan
New tests were added for
String
andSubstring
.Benchmarks
New benchmarks were added for
String
andSubstring
.It looks like there might not be easy support to write benchmarks for symbols that have not yet shipped to prod:
AFAIK we do not have access to
SwiftStdlib 6.3
from benchmarks… so we guard with9999
. My understanding is we then clean this up with a follow up diff once we know the exact OS versions thatSwiftStdlib 6.3
maps to.2Footnotes
https://github.com/swiftlang/swift/blob/swift-6.1.2-RELEASE/stdlib/public/core/String.swift#L397-L415 ↩
https://github.com/swiftlang/swift/pull/74366/files ↩