Description

Adds new method for relocating elements within an OrderedSet and OrderedDictionary:

extension OrderedSet {
  mutating func moveSubrange(_ range: some RangeExpression<Index>, to destination: Index)
  mutating func move(members: some Sequence<Element>, to destination: Index)
  mutating func move(indices: some Sequence<Index>, to destination: Index)
}
extension OrderedDictionary {
  mutating func moveSubrange(_ range: some RangeExpression<Index>, to destination: Index)
  mutating func move(keys: some Sequence<Key>, to destination: Index)
  mutating func move(indices: some Sequence<Index>, to destination: Index)
}

This fills a gap that comes up regularly in drag-and-drop UIs and other reordering workflows: today users have to fall back to remove(at:) + insert(_:at:), which is O(count * k) and re-hashes elements unnecessarily.

Performance

12 new benchmarks in OrderedSetBenchmarks cover the public API across the four dispatch paths. The charts below were produced by disabling the fast paths selectively.

Fast path 1: contiguous-range detection in move(_:Sequence). When the input forms a contiguous range, dispatching to the range-rotation path avoids the compact-and-place allocation.

Fast path 2: contiguous-reordered detection. When the sorted sources are contiguous but the input is in a different order, rotation followed by in-place permutation beats compact-and-place.

Fast path 3: targeted hash updates in move(_:Range). For small range moves over short distances, touching just the affected buckets beats scanning the whole hash table.

Fast path 4: targeted hash updates in scattered moves. When the affected region is small relative to table capacity, per-element bucket updates beat a full hash-table rebuild.

All benchmarks:

Source Impact

Additive.

Checklist

• I've read the Contribution Guidelines
• My contributions are licensed under the Swift license.
• I've followed the coding style of the rest of the project.
• I've added tests covering all new code paths my change adds to the project (to the extent possible).
• I've added benchmarks covering new functionality (if appropriate).
• I've verified that my change does not break any existing tests or introduce unexpected benchmark regressions.
• I've updated the documentation (if appropriate).