[Accepted with modifications] SE-0494: Add `isIdentical(to:)` methods for quick comparison to concrete types

Evolution Announcements
1

Hello, Swift community.

The review of SE-0494 ran from September 22nd to October 13th, 2025. This period includes a one-week extension to discuss a revision that the LSG requested after considering the initial feedback.

The community's feedback in the review thread was spirited. Overall, community members generally (1) supported the addition of the API but (2) expressed concern about the name. This is what caused the LSG to suggest the revision of renaming the method to isTriviallyIdentical(to:). Subsequent community feedback seemed to broadly support that change, although a few objections and counter-proposals were floated.

Triviality is both a somewhat technical concept and a somewhat imprecise and overloaded one. Mathematics gives it one meaning, languages like C++ another, normal English usage still another. Swift has specifically avoided it in the past, e.g. with BitwiseCopyable.[1] But we have not found an appealing alternative, and isTriviallyIdentical(to:) does seem to suggest the right things, both of being cheap and of being not the same thing as equality. The LSG has therefore decided to move forward with this name.

The LSG discussed what to do with the existing methods on Span. We have decided that the Span types should add methods with these names, and we are still considering whether to formally deprecate the existing ones. We do not believe there is a need for further evolution review on that topic, however.

Accordingly, SE-0494 is accepted with modifications: specifically, to rename the new methods to isTriviallyIdentical(to:) and to add them to the Span types as well.

As always, I'd like to thank the community for its thoughtful contributions during the pitch and review of this proposal. The community's involvement helps to make Swift a better language.

John McCall
Review Manager

  1. The LSG specifically discussed isBitwiseIdentical(to:) and decided that it was not a good name. We don't want clients or implementors to be focused on bit-level representation details, and we don't want APIs feel like they have to use a different name just because their check is slightly more involved than a memcmp. ↩︎

22 Likes
2

I do not claim it would. I believe there's a misunderstanding. I am not suggesting a change to how isIdentical(to:) ought to function. My issue is that the proposal is written ambiguously, and has misled several first-time readers into what the proposal would do. I am suggesting a couple of improvements to the text for clarity. Let me collect those here for the sake of discussion.

First, the "Introduction" ought to read:

We propose a new instance method isIdentical(to:) which returns true if two objects can be determined to be equal in constant time; or false otherwise.

If I understand the proposal correctly, this should not represent a change to its behavior, just a clarification.

Second, I understand the "Considered Alternatives" to list implementations that also work, but might be inferior for one reason or another. It is not necessary for the alternative to work in all cases, as long as there is some situation where the Proposal would be superior to the Considered Alternative. There may also cases where maybe the "Considered Alternative" seems similar at first glance, but has nothing in common with the proposal, and ought to be clarified for the reader.

In this proposal, there are a certain set of cases that frequently perform comparison between two objects. If I am trying to cache the output of a function, I might use a Dictionary. However given this proposal, maybe it would be better to use a Memoizer that calls isIdentical(to:). This would also help describe for new readers the difference between various ways of testing for equality (that are in fact somewhat different).

3

I think your comments are well-taken, but maybe this isn't the right place to continue this.

1 Like
4

SGTM. Thanks!

We also disucssed supporting Unsafe[Mutable][Raw]BufferPointer types with this operation… would the accepted proposal include those as well?

5

"Seem" is in the region of the beholder.

Screenshot 2025-10-15 at 9.25.00 PM
Screenshot 2025-10-15 at 9.25.00 PM1210×448 45.2 KB

I didn't follow the discussion and am going to have to option-click to find out what "trivial" is supposed to mean, here. It's not obvious to me. But if it's correct, that's fine. I'm happy to learn. It's no different than whatever an "InlineArray" is. Please try not to leave undefined terms like "out-of-line" in the description for this new function.

6

I read the initial discussion but didn't follow because it's so long. I did a full text search for "trivial" in the thread but it didn't work (no result showed up). Gemini suggests it might be because "Discourse uses a database index to speed up searches, and for very long or frequently updated topics, the index can become out of sync with the live content, especially if the topic exceeds certain performance limits."

Fortunately Gemini also gives an excellent explanation about what "trivial" means:

Adding the prefix "trivially" to a function name like isTriviallyIdentical(to:) is a highly specific and technical naming convention that most likely means the check is performed in the simplest, most direct, and most performant way possible. It is a strong signal to other developers that the function is an extremely fast and low-level check, not a deep or complex one.

The origin of the technical use of "trivial" comes from its roots in mathematics and logic. In both fields, a "trivial" case or proof is one that is so simple and obvious that it requires little or no effort to demonstrate. This meaning was later adopted by computer science, particularly in low-level and systems programming.

isTriviallyIdentical(to:) is preferred over isKnownIdentical(to:) for a proposed function because "trivial" better communicates that the check is a fast, constant-time performance optimization rather than a deep or semantic comparison. This name was seen as more precise in indicating the low-level nature of the check and managing developer expectations.

PS: Gemini gave a great answer about "out-of-line region" too:

In computer science, an out-of-line region refers to a block of memory that is allocated separately from the object that refers to it. For data structures like arrays, this means the elements are not stored directly inside the memory allocated for the array variable itself.

Hope it help :)

7

It would if this discussion were linked directly via option-clicking the definitions. Without that integration, AI takes too long to use.
For as uninformative as the InlineArray documentation is, it would be a better idea for now, to do just that. I hope that a little more time can be devoted to isIdentical.

8

I wrote that overview of InlineArray in swiftlang/swift#79800. Everyone is welcome to contribute improvements to the documentation. For example, the shorthand syntax of SE-0483 should probably be introduced.

EDIT: see swiftlang/swift#84978 by @xwu.

5 Likes
9

Great work everyone! Looking forward to using this one.

1 Like