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

vanvoorden · 2025-06-06T07:31:58Z

Background

SE-0494 has been accepted by LSG.

Changes

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.4, *)
  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.

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

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

Availability

This code will require 6.4. We do not currently have a 6.4 version definition ready. We add that here.

Test Plan

New tests were added for String and Substring.

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

vanvoorden · 2025-06-12T18:47:32Z

@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!)

stdlib/public/core/String.swift

stdlib/public/core/Substring.swift

vanvoorden · 2025-10-16T22:53:43Z

(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 · 2025-10-20T18:24:01Z

benchmark/single-source/StringTests.swift

        tags: [.validation, .String]))
  }
+
+  if #available(macOS 9999, iOS 9999, tvOS 9999, watchOS 9999, visionOS 9999, *) {


@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?

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

@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 · 2025-10-20T19:25:44Z

@swift-ci Please smoke test

vanvoorden · 2025-12-09T01:37:14Z

@swift-ci Please test

vanvoorden · 2025-12-09T01:37:32Z

@swift-ci please Apple silicon benchmark

vanvoorden · 2025-12-09T01:37:39Z

@swift-ci Please benchmark

vanvoorden · 2025-12-09T01:37:46Z

@swift-ci Please Build Toolchain macOS Platform

vanvoorden · 2025-12-09T05:24:06Z

stdlib/public/core/Availability.swift

  @_alwaysEmitIntoClient
  public static var v6_3_0: Self { Self(_value: 0x060300) }
+  @_alwaysEmitIntoClient
+  public static var v6_4_0: Self { Self(_value: 0x060400) }


[2025-12-09T04:52:54.512Z] FAIL: Swift(macosx-x86_64) :: abi/macOS/x86_64/stdlib-asserts.swift (10622 of 20420, 6 of 6 attempts) [2025-12-09T04:52:54.512Z] ******************** TEST 'Swift(macosx-x86_64) :: abi/macOS/x86_64/stdlib-asserts.swift' FAILED ******************** [2025-12-09T04:52:54.512Z] Exit Code: 1 [2025-12-09T04:52:54.512Z] [2025-12-09T04:52:54.512Z] Command Output (stdout): [2025-12-09T04:52:54.512Z] -- [2025-12-09T04:52:54.512Z] --- /Users/ec2-user/jenkins/workspace/swift-PR-macos/branch-main/swift/test/abi/macOS/x86_64/../../Inputs/macOS/x86_64/stdlib/baseline-asserts 2025-12-09 02:24:28 [2025-12-09T04:52:54.512Z] +++ /Users/ec2-user/jenkins/workspace/swift-PR-macos/branch-main/build/buildbot_incremental/swift-macosx-x86_64/test-macosx-x86_64/abi/macOS/x86_64/Output/stdlib-asserts.swift.tmp/symbols 2025-12-09 04:52:54 [2025-12-09T04:52:54.512Z] @@ -3385,6 +3385,7 @@ [2025-12-09T04:52:54.512Z] _$sSo19_SwiftStdlibVersionas23CustomStringConvertiblesWP [2025-12-09T04:52:54.512Z] _$sSo19_SwiftStdlibVersionasE11descriptionSSvg [2025-12-09T04:52:54.512Z] _$sSo19_SwiftStdlibVersionasE11descriptionSSvpMV [2025-12-09T04:52:54.512Z] +_$sSo19_SwiftStdlibVersionasE6v6_4_0ABvpZMV [2025-12-09T04:52:54.512Z] _$sSo19_SwiftStdlibVersionasE7currentABvgZ [2025-12-09T04:52:54.512Z] _$sSp10deallocate8capacityySi_tF [2025-12-09T04:52:54.512Z] _$sSp10deallocateyyF

@lorentey I think this one led to a failure from the stdlib-asserts.swift… but I thought aeic did not trigger the ABI tests?

I found 58dec75 and 1434440. So I think we also need to add the 6.4 here?

@lorentey I think this one led to a failure from the stdlib-asserts.swift… but I thought aeic did not trigger the ABI tests?

This is a property descriptor to support reflection; its export is somewhat questionable, but it's expected! It should be added to the expectation files (for both arm64 and Intel), just like the others.

The property itself is backdeployable; do not add an availability declaration to it.

vanvoorden · 2025-12-09T17:35:51Z

@swift-ci Please test

vanvoorden · 2025-12-10T03:39:06Z

@swift-ci please Apple silicon benchmark

vanvoorden · 2025-12-10T03:39:15Z

@swift-ci Please benchmark

vanvoorden · 2025-12-10T03:39:46Z

@swift-ci Please Build Toolchain macOS Platform

vanvoorden · 2025-12-11T17:54:49Z

@lorentey This one LGTM. Can you please help us land these changes on main? Thanks!

finagolfin · 2025-12-12T08:50:43Z

This pull appears to have broken a C++ Interop test on the trunk Android CI:

09:07:34  In file included from /home/build-user/build/swift-project/Ninja-Release/swift-linux-x86_64/test-android-aarch64/Interop/SwiftToCxx/stdlib/Output/stdlib-in-cxx-no-diagnostics-generated-header.cpp.tmp/test-stdlib.cpp:2:
09:07:34  /home/build-user/build/swift-project/Ninja-Release/swift-linux-x86_64/test-android-aarch64/Interop/SwiftToCxx/stdlib/Output/stdlib-in-cxx-no-diagnostics-generated-header.cpp.tmp/Stringer.h:754:241: error: unknown platform 'visionos' in availability macro [-Werror,-Wavailability]
09:07:34    754 | SWIFT_EXTERN bool $sSS20isTriviallyIdentical2toSbSS_tF(struct swift_interop_passStub_swift_uint64_t_0_8_void_ptr_8_16 other, struct swift_interop_passStub_swift_uint64_t_0_8_void_ptr_8_16 _self) SWIFT_NOEXCEPT SWIFT_CALL SWIFT_AVAILABILITY(visionos,introduced=9999) SWIFT_AVAILABILITY(tvos,introduced=9999) SWIFT_AVAILABILITY(watchos,introduced=9999) SWIFT_AVAILABILITY(ios,introduced=9999) SWIFT_AVAILABILITY(macos,introduced=9999); // isTriviallyIdentical(to:)
09:07:34        |                                                                                                                                                                                                                                                 ^
09:07:34  /home/build-user/build/swift-project/Ninja-Release/swift-linux-x86_64/test-android-aarch64/Interop/SwiftToCxx/stdlib/Output/stdlib-in-cxx-no-diagnostics-generated-header.cpp.tmp/Stringer.h:795:251: error: unknown platform 'visionos' in availability macro [-Werror,-Wavailability]
09:07:34    795 | SWIFT_EXTERN bool $sSS8UTF8ViewV20isTriviallyIdentical2toSbAB_tF(struct swift_interop_passStub_swift_uint64_t_0_8_void_ptr_8_16 other, struct swift_interop_passStub_swift_uint64_t_0_8_void_ptr_8_16 _self) SWIFT_NOEXCEPT SWIFT_CALL SWIFT_AVAILABILITY(visionos,introduced=9999) SWIFT_AVAILABILITY(tvos,introduced=9999) SWIFT_AVAILABILITY(watchos,introduced=9999) SWIFT_AVAILABILITY(ios,introduced=9999) SWIFT_AVAILABILITY(macos,introduced=9999); // isTriviallyIdentical(to:)
09:07:34        |                                                                                                                                                                                                                                                           ^
09:07:34  /home/build-user/build/swift-project/Ninja-Release/swift-linux-x86_64/test-android-aarch64/Interop/SwiftToCxx/stdlib/Output/stdlib-in-cxx-no-diagnostics-generated-header.cpp.tmp/Stringer.h:1943:149: error: unknown platform 'visionos' in availability macro [-Werror,-Wavailability]
09:07:34   1943 |   SWIFT_INLINE_THUNK bool isTriviallyIdenticalTo(const String& other) const SWIFT_SYMBOL("s:SS20isTriviallyIdentical2toSbSS_tF") SWIFT_AVAILABILITY(visionos,introduced=9999) SWIFT_AVAILABILITY(tvos,introduced=9999) SWIFT_AVAILABILITY(watchos,introduced=9999) SWIFT_AVAILABILITY(ios,introduced=9999) SWIFT_AVAILABILITY(macos,introduced=9999);
09:07:34        |                                                                                                                                                     ^
09:07:34  /home/build-user/build/swift-project/Ninja-Release/swift-linux-x86_64/test-android-aarch64/Interop/SwiftToCxx/stdlib/Output/stdlib-in-cxx-no-diagnostics-generated-header.cpp.tmp/Stringer.h:2100:177: error: unknown platform 'visionos' in availability macro [-Werror,-Wavailability]
09:07:34   2100 |   SWIFT_INLINE_THUNK bool isTriviallyIdenticalTo(const __StringNested::UTF8View& other) const SWIFT_SYMBOL("s:SS8UTF8ViewV20isTriviallyIdentical2toSbAB_tF") SWIFT_AVAILABILITY(visionos,introduced=9999) SWIFT_AVAILABILITY(tvos,introduced=9999) SWIFT_AVAILABILITY(watchos,introduced=9999) SWIFT_AVAILABILITY(ios,introduced=9999) SWIFT_AVAILABILITY(macos,introduced=9999);
09:07:34        |                                                                                                                                                                                 ^
09:07:34  /home/build-user/build/swift-project/Ninja-Release/swift-linux-x86_64/test-android-aarch64/Interop/SwiftToCxx/stdlib/Output/stdlib-in-cxx-no-diagnostics-generated-header.cpp.tmp/Stringer.h:2684:104: error: unknown platform 'visionos' in availability macro [-Werror,-Wavailability]
09:07:34   2684 |   SWIFT_INLINE_THUNK bool String::isTriviallyIdenticalTo(const String& other) const SWIFT_AVAILABILITY(visionos,introduced=9999) SWIFT_AVAILABILITY(tvos,introduced=9999) SWIFT_AVAILABILITY(watchos,introduced=9999) SWIFT_AVAILABILITY(ios,introduced=9999) SWIFT_AVAILABILITY(macos,introduced=9999) {
09:07:34        |                                                                                                        ^
09:07:34  /home/build-user/build/swift-project/Ninja-Release/swift-linux-x86_64/test-android-aarch64/Interop/SwiftToCxx/stdlib/Output/stdlib-in-cxx-no-diagnostics-generated-header.cpp.tmp/Stringer.h:2736:140: error: unknown platform 'visionos' in availability macro [-Werror,-Wavailability]
09:07:34   2736 |   SWIFT_INLINE_THUNK bool __StringNested::UTF8View::isTriviallyIdenticalTo(const __StringNested::UTF8View& other) const SWIFT_AVAILABILITY(visionos,introduced=9999) SWIFT_AVAILABILITY(tvos,introduced=9999) SWIFT_AVAILABILITY(watchos,introduced=9999) SWIFT_AVAILABILITY(ios,introduced=9999) SWIFT_AVAILABILITY(macos,introduced=9999) {
09:07:34        |                                                                                                                                            ^
09:07:34  6 errors generated.

I checked the Stringer.h generated by the compiler in this test for Android a month ago, and there was no such use of SWIFT_AVAILABILITY macros or mention of visionos back then, so something about the new availability attributes in this pull seems to have added it.

@madsodgaard, any idea what's going on here?

vanvoorden · 2025-12-12T17:39:14Z

@finagolfin Ahh… crap. I did not think to run CI jobs on Android before landed. That's on me. Sorry about that!

Hmm… can I repro this error building locally from a macOS machine? How would I repro this other than the CI job?

finagolfin · 2025-12-12T18:32:53Z

Ahh… crap. I did not think to run CI jobs on Android before landed. That's on me. Sorry about that!

No, not at all, Android is not officially supported yet, just some early snapshots, and there is no way to trigger the Android CI manually as of yet, still adding that.

can I repro this error building locally from a macOS machine? How would I repro this other than the CI job?

You can't, so nobody is faulting you for this. We will have to look into it locally on a linux host and see what we find.

If you have any idea why this might be happening, your advice would be useful.

vanvoorden · 2025-12-12T18:40:45Z

If you have any idea why this might be happening, your advice would be useful.

Hmm… trying to think… this diff introduces a new SwiftStdlib definition for the "new" 6.4 version:

SwiftStdlib 6.2:macOS 26.0, iOS 26.0, watchOS 26.0, tvOS 26.0, visionOS 26.0
SwiftStdlib 6.3:macOS 9999, iOS 9999, watchOS 9999, tvOS 9999, visionOS 9999
+ SwiftStdlib 6.4:macOS 9999, iOS 9999, watchOS 9999, tvOS 9999, visionOS 9999

And our build scripts then implicitly generate for us the StdlibDeploymentTarget 6.4 definition that we actually use to guard our API definition.

If StdlibDeploymentTarget 6.3 was also leading to build errors then I guess that would be an interesting sign… but apparently we only see build errors here from StdlibDeploymentTarget 6.4… which is weird.

If we are blocked on a local repro one experiment might be to try and see if refactoring the StdlibDeploymentTarget 6.4 back to SwiftStdlib 6.4 directly fixes the errors by running a test diff on a CI job. There are other reasons we want to ship StdlibDeploymentTarget instead of SwiftStdlib directly but it's possible this might be leading to some weird behavior for some reason?

BTW… am I able to download the build archive artifacts of the job that failed? I am not able to see that from the Jenkins link.

finagolfin · 2025-12-12T18:52:09Z

There are other reasons we want to ship StdlibDeploymentTarget instead of SwiftStdlib directly but it's possible this might be leading to some weird behavior for some reason?

Thanks, we will look into that.

am I able to download the build archive artifacts of the job that failed?

You want to see the Android SDK that was being built or the test scripts/results? I don't think any of the CI jobs make available the latter, while the former is not fully built when the CI job fails, which it does if any of the compiler validation tests do not pass.

vanvoorden · 2025-12-12T18:56:03Z

You want to see the Android SDK that was being built or the test scripts/results?

I was thinking about looking at the actual output of Stringer.h. This diff seems to be adding SWIFT_AVAILABILITY and visionos in a new way… so I guess one question then is what happens to the APIs that are currently guarded from stdlib with SwiftStdlib 6.3 or StdlibDeploymentTarget 6.3? What do those APIs look like in Stringer.h?

finagolfin · 2025-12-14T08:48:39Z

Alright, looked into this, by applying your pull locally in an Android test run and examining the resulting generated stdlib String headers in that test, plus how other Swift stdlib APIs apply these annotations. It appears that your pull, which merely uses these availability annotations more, turned up a latent bug in how these C++ Interop tests are run for non-Darwin availability platforms, with this C++ Interop test that was working for more than a year now failing.

The tests use the file availability-macros.def to map these stdlib annotations to the concrete OS versions that the Swift compiler recognizes, but ever since Mads added availability support for Android more than a month ago, #84574, we simply haven't hit this because not many stdlib APIs use this StdlibDeploymentTarget annotation, almost all in Concurrency and Duration, with no public APIs in String:

> grep -r "StdlibDeploymentTarget \d" stdlib/public | cut -f1 -d:| uniq -c
   8 stdlib/public/core/StringWordBreaking.swift
   1 stdlib/public/core/StringUTF8View.swift
   1 stdlib/public/core/Instant.swift
   1 stdlib/public/core/StringUnicodeScalarView.swift
   4 stdlib/public/core/Substring.swift
   1 stdlib/public/core/StringUTF16View.swift
   4 stdlib/public/core/DurationProtocol.swift
   1 stdlib/public/core/String.swift
  38 stdlib/public/core/Duration.swift
   1 stdlib/public/Concurrency/PlatformExecutorCooperative.swift
  55 stdlib/public/Concurrency/Executor.swift
  14 stdlib/public/Concurrency/Clock.swift
   1 stdlib/public/Concurrency/PlatformExecutorNone.swift
   7 stdlib/public/Concurrency/ExecutorImpl.swift
   1 stdlib/public/Concurrency/PlatformExecutorWindows.swift
   8 stdlib/public/Concurrency/CooperativeExecutor.swift
   5 stdlib/public/Concurrency/DispatchExecutor.swift
   2 stdlib/public/Concurrency/CFExecutor.swift
   2 stdlib/public/Concurrency/UnimplementedExecutor.swift
   5 stdlib/public/Concurrency/TaskSleepDuration.swift
   2 stdlib/public/Concurrency/TaskSleep.swift
   1 stdlib/public/Concurrency/GlobalConcurrentExecutor.swift
   1 stdlib/public/Concurrency/PlatformExecutorDarwin.swift
  30 stdlib/public/Concurrency/PartialAsyncTask.swift
   3 stdlib/public/Concurrency/Task.swift
  13 stdlib/public/Concurrency/SuspendingClock.swift
  10 stdlib/public/Concurrency/ContinuousClock.swift
  21 stdlib/public/Concurrency/ExecutorBridge.swift
   1 stdlib/public/Concurrency/PlatformExecutorLinux.swift

Once you added these new String APIs, this single test that checks for the public String APIs exported to a C++ header exposed this availability bug, which we'll now have to fix.

@lorentey and @Xazax-hun, let me know if I got that right, as I'm using these availability features for the first time, and how we should fix this. Until then, I'm XFAILing this lone C++ Interop test on Android for now, #86034.

…stdlib 6.4 annotations in #82055 (#86034) This should [get the Android CI green](https://ci.swift.org/job/oss-swift-package-swift-sdk-for-android/137/console) again, until we can figure out how we want to handle this matter.

Xazax-hun · 2025-12-15T10:58:41Z

let me know if I got that right, as I'm using these availability features for the first time, and how we should fix this. Until then, I'm XFAILing this lone C++ Interop test on Android for now, #86034.

Unfortunately, I am not too familiar with availability but everything you wrote sounds reasonable to me. Could you open a github ticket to address this issue?

finagolfin · 2025-12-16T09:48:21Z

Done, filed in #86085.

vanvoorden force-pushed the string-identical branch 4 times, most recently from b140d00 to 7634c46 Compare June 12, 2025 03:35

vanvoorden changed the title ~~[WIP][DNM] Add isIdentical Methods for Quick Comparisons to String and Substring~~ [RFC][DNM] Add isIdentical Methods for Quick Comparisons to String and Substring Jun 12, 2025

vanvoorden force-pushed the string-identical branch 5 times, most recently from 7462596 to e6db03f Compare June 16, 2025 18:43

vanvoorden changed the title ~~[RFC][DNM] Add isIdentical Methods for Quick Comparisons to String and Substring~~ [StdLib][RFC][DNM] Add isIdentical Methods for Quick Comparisons to String and Substring Jun 23, 2025

vanvoorden force-pushed the string-identical branch 2 times, most recently from 09d49a8 to 56da8c0 Compare June 24, 2025 07:26

vanvoorden mentioned this pull request Jun 24, 2025

[SE-0494][StdLib] Add isTriviallyIdentical(to:) Methods to Array, ArraySlice, and ContiguousArray #82438

Merged

vanvoorden force-pushed the string-identical branch from 3a0f013 to 2b63da1 Compare August 11, 2025 20:44

vanvoorden marked this pull request as ready for review August 12, 2025 07:06

vanvoorden requested review from a team and eeckstein as code owners August 12, 2025 07:06

vanvoorden mentioned this pull request Aug 22, 2025

[RFC] Add isIdentical Methods to Concrete Types vanvoorden/swift-evolution#1

Closed

vanvoorden force-pushed the string-identical branch 2 times, most recently from d26fa93 to 753979f Compare August 26, 2025 00:51

vanvoorden force-pushed the string-identical branch from 753979f to e0a2726 Compare September 3, 2025 22:58

vanvoorden changed the title ~~[StdLib][RFC][DNM] Add isIdentical Methods for Quick Comparisons to String and Substring~~ [SE-0494][StdLib] Add isTriviallyIdentical(to:) Methods for Quick Comparisons to String and Substring Oct 16, 2025

vanvoorden force-pushed the string-identical branch from e0a2726 to e694f86 Compare October 16, 2025 21:42

lorentey reviewed Oct 16, 2025

View reviewed changes

stdlib/public/core/String.swift Outdated Show resolved Hide resolved

stdlib/public/core/Substring.swift Outdated Show resolved Hide resolved

vanvoorden mentioned this pull request Oct 17, 2025

[SE-0494][StdLib] Add isTriviallyIdentical(to:) Methods #84991

Closed

vanvoorden commented Oct 20, 2025

View reviewed changes

WindowsMEMZ and others added 6 commits December 8, 2025 17:32

Add isIdentical to StringGuts and use it for comparation

288a698

Update tests for availability checking

8055d91

[stdlib] Update availability of String view additions

4cde919

[stdlib] String, Substring: Use new _StringGuts helper

e5787c6

[test] Update tests, acknowledging new additions

a3650e7

substring test nits

8c9f084

vanvoorden force-pushed the string-identical branch from 26a64f5 to 8c9f084 Compare December 9, 2025 01:36

vanvoorden commented Dec 9, 2025

View reviewed changes

add 6.4 symbols to abi tests

0ab8884

lorentey merged commit a233485 into swiftlang:main Dec 11, 2025
8 checks passed

finagolfin mentioned this pull request Dec 16, 2025

[Test] Adding String methods annotated with StdlibDeploymentTarget 6.4 in #82055 broke a C++ Interop test on the Android CI #86085

Open

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

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

Uh oh!

Conversation

vanvoorden commented Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Background

Changes

Availability

Test Plan

Footnotes

Uh oh!

vanvoorden commented Jun 12, 2025

Uh oh!

lorentey left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

vanvoorden commented Oct 16, 2025

Uh oh!

vanvoorden Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

Azoy Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

vanvoorden Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

vanvoorden commented Oct 20, 2025

Uh oh!

vanvoorden commented Dec 9, 2025

Uh oh!

vanvoorden commented Dec 9, 2025

Uh oh!

vanvoorden commented Dec 9, 2025

Uh oh!

vanvoorden commented Dec 9, 2025

Uh oh!

vanvoorden Dec 9, 2025

Choose a reason for hiding this comment

Uh oh!

vanvoorden Dec 9, 2025

Choose a reason for hiding this comment

Uh oh!

lorentey Dec 9, 2025

Choose a reason for hiding this comment

Uh oh!

vanvoorden commented Dec 9, 2025

Uh oh!

vanvoorden commented Dec 10, 2025

Uh oh!

vanvoorden commented Dec 10, 2025

Uh oh!

vanvoorden commented Dec 10, 2025

Uh oh!

vanvoorden commented Dec 11, 2025

Uh oh!

Uh oh!

finagolfin commented Dec 12, 2025

Uh oh!

vanvoorden commented Dec 12, 2025

Uh oh!

finagolfin commented Dec 12, 2025

Uh oh!

vanvoorden commented Dec 12, 2025

Uh oh!

finagolfin commented Dec 12, 2025

Uh oh!

vanvoorden commented Dec 12, 2025

Uh oh!

finagolfin commented Dec 14, 2025

Uh oh!

Xazax-hun commented Dec 15, 2025

Uh oh!

finagolfin commented Dec 16, 2025

Uh oh!

Reviewers

Assignees

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

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

vanvoorden commented Jun 6, 2025 •

edited

Loading