[Call for Volunteers] Add `isTriviallyIdentical(to:)` Methods to More Concrete Types

Our SE-0494 proposal added new isTriviallyIdentical(to:) instance methods to concrete types for quickly determining if two instances must be equal by-value.

We added this method to the following types from Standard Library:

  • String
  • String.UnicodeScalarView
  • String.UTF16View
  • String.UTF8View
  • Substring
  • Substring.UnicodeScalarView
  • Substring.UTF16View
  • Substring.UTF8View
  • Array
  • ArraySlice
  • ContiguousArray
  • Dictionary
  • Set
  • UnsafeBufferPointer
  • UnsafeMutableBufferPointer
  • UnsafeMutableRawBufferPointer
  • UnsafeRawBufferPointer
  • UTF8Span
  • Span
  • RawSpan

That's a lot of types… but we also considered more types from Standard Library during our pitch and review:

  • Character
  • Dictionary.Keys
  • Dictionary.Values
  • KeyValuePairs
  • StaticBigInt
  • StaticString

The following types from Foundation also look like good candidates for this method:

  • AttributedString
  • AttributedSubstring
  • Data

For our original proposal we made the decision to concentrate on what we saw as the most high-impact types from Standard Library. We didn't go so far as to say adding isTriviallyIdentical(to:) to these new types would be wrong… we just did not prioritize it at that very moment in time.

A potential “second round” proposal review could add isTriviallyIdentical(to:) to some or all of these types. We could even include types that are not yet listed here.

Call for Volunteers

Are you interested in helping? Have you thought about participating in the review process but didn't know where to get started? Are you looking to increase the scope of your impact beyond your immediate team?

I think this would make a great proposal for a first-time author. A lot of the “heavy lifting” was completed during our first proposal review. We all made some basic agreements about semantics and we picked a name that we felt best described what this operation does. A new proposal for these new types could follow the precedent that was established from our last proposal. These new types could adopt isTriviallyIdentical(to:) with the same semantics we are already shipping.

The biggest place I see for a new author to drive the direction of this new proposal would be to choose exactly which types are included. Keep in mind that proposal authors should have working implementations ready before proposal review begins. You can investigate whether or not isTriviallyIdentical(to:) is possible on these types. If it is possible then you can investigate if the impact from shipping is worth the time spent writing and maintaining the implementation.

I do have some draft implementations you might want to look at on some of these types.[1][2][3] I can't completely guarantee right now these are all robust and correct… but these look like pretty good places you might want to start if you were interested in working on these implementations.

My preference is that a new volunteer from the community should be the primary lead author on a new proposal. But I could also volunteer to make myself available for free coaching and mentoring through this process assuming the volunteer is a first-time proposal author. My primary goal would not be to “take over” a review thread: this should still be you putting yourself forward as the “lead” engineer on this project. If you felt like me getting involved would be a big help I could post for you to help answer questions during review. But I would also want to explore options where I could coach or mentor you to the point where you felt comfortable enough to navigate a review on your own — and obviously with the help of a review manager from LSG.

Some general nice-to-haves — not requirements — before getting started:

  • You have already made changes to Standard Library or another “official” Swift package.
  • You are experienced with CI build jobs on large projects and can identify why jobs might have failed.
  • You have already participated in RFC design reviews on a smaller team or project.

Those are not requirements to get started… but IMO that would be very good experience to have for some of the new challenges if you choose to author this proposal.

If this sounds like something you might be interested in please let me know!


  1. https://forums.swift.org/t/-/80496/29 ↩︎

  2. https://github.com/swiftlang/swift-foundation/pull/1385 ↩︎

  3. https://github.com/swiftlang/swift-foundation/pull/1384 ↩︎

1 Like