# \[Pitch #2\] Add \`isIdentical\` Methods for Quick Comparisons to Concrete Types

**URL:** <https://forums.swift.org/t/pitch-2-add-isidentical-methods-for-quick-comparisons-to-concrete-types/80496>\
**Category:** Pitches\
**Created:** [June 16, 2025, 6:00pm UTC](https://forums.swift.org/t/pitch-2-add-isidentical-methods-for-quick-comparisons-to-concrete-types/80496 "2025-06-16T18:00:16Z")\
**Posts on this page:** 1\
**Showing post:** 83

<div class="post-metadata">

**Author:** ![vanvoorden](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/vanvoorden/32/33619_2.png) [@vanvoorden](https://forums.swift.org/u/vanvoorden)\
**Post date:** [August 19, 2025, 6:18am UTC](https://forums.swift.org/t/pitch-2-add-isidentical-methods-for-quick-comparisons-to-concrete-types/80496/83 "2025-08-19T06:18:04Z")

</div>

> [@xwu](#):
>
> > [@vanvoorden](#):
> >
> > One missing piece we saw previously is that when `T` is not `Equatable` we do not formally define under what conditions `isIdentical` ever returns `false`.
> 
> At the risk of sounding like a broken record, we ought to have good, real-world motivating examples for the use of this API to determine our desired semantics. For instance, for values of some type `T` that are _never_ `Equatable`, what can one usefully do that `isIdentical` would make faster or more expressive?

I don't really understand what this comment is asking for. This comment is implying that we should determine our desired semantics from "real-world motivating examples". But this comment is _specifically_ directed at my attempt to begin to define semantics across _any_ type that implements `isIdentical`. I _can't_ give you real-world examples… it's _already_ a discussion about an abstract type.

That being said… the clear prior art in this space is `Span.isIdentical`. `Span` is not `Equatable`. Here is _all_ [SE-0447](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0447-span-access-shared-contiguous-storage.md) tells us about `isIdentical`:

> ##### Identifying whether a `Span` is a subrange of another:
> 
> When working with multiple `Span` instances, it is often desirable to know whether one is identical to or a subrange of another. We include functions to determine whether this is the case, as well as a function to obtain the valid offsets of the subrange within the larger span:
> 
> ```swift
> extension Span where Element: ~Copyable {
> /// Returns true if the other span represents exactly the same memory
> public func isIdentical(to span: borrowing Self) -> Bool
>   
> /// Returns the indices within `self` where the memory represented by `span`
> /// is located, or `nil` if `span` is not located within `self`.
> ///
> /// Parameters:
> /// - span: a span that may be a subrange of `self`
> /// Returns: A range of offsets within `self`, or `nil`
> public func indices(of span: borrowing Self) -> Range<Index>?
> }
> 
> ```

Across 30 comments in a [pitch thread](https://forums.swift.org/t/pitch-safe-access-to-contiguous-storage/69888), 36 comments in a [second pitch thread](https://forums.swift.org/t/pitch-2-safe-access-to-contiguous-storage/72745/), and 78 comments in a [review thread](https://forums.swift.org/t/se-0447-span-safe-access-to-contiguous-storage/74676), _not one_ engineer asked for real-world examples to justify the inclusion of an `isIdentical` function and _not one_ engineer asked for an additional discussion to clarify the semantics of the `isIdentical` function.

What I am _not_ saying is that _every_ attempt to ship a new type in standard library that implements `isIdentical` and _is not_ `Equatable` _must not_ present real-world motivating examples during design review. That is a decision that can take place between a proposal author and LSG. If LSG makes the decision that a new type _should_ present real-world motivating examples during a proposal review then the proposal author can present those examples. I have zero problem with this.

What I _am_ saying is that I am _not_ persuaded that we _must_ enforce here — in _this_ proposal — that _every_ type that implements `isIdentical` and is not `Equatable` _must_ present real-world motivating examples. This _clearly_ is not a requirement that must always be enforced — just look at `Span`.

> [@xwu](#):
>
> For that matter, what concrete types in the stdlib that are never `Equatable` are we thinking about here?

All the concrete types in this specific proposal are either _always_ `Equatable` (like `String`) or _conditionally_ `Equatable` (like Array).

While `Span` predates this proposal I do believe it would be desirable if the discussion of what "general" behaviors we want and expect `isIdentical` to adopt "in the abstract" could conceptually "backdeploy" to what already shipped on `Span`. But I am not 100 percent committed to this POV and I can drop this if it slows us down from shipping this.

---

_[View the full topic](https://forums.swift.org/t/pitch-2-add-isidentical-methods-for-quick-comparisons-to-concrete-types/80496)._