{"id":50832,"date":"2026-01-27T14:08:05","date_gmt":"2026-01-27T19:08:05","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=50832"},"modified":"2026-03-18T10:36:35","modified_gmt":"2026-03-18T14:36:35","slug":"swift-pitch-borrowing-sequence","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/01\/27\/swift-pitch-borrowing-sequence\/","title":{"rendered":"Swift Pitch: Borrowing Sequence"},"content":{"rendered":"

Ben Cohen<\/a>:<\/p>\n

\n

A sequence provides access to its elements through an Iterator<\/code>,\nand an iterator’s next()<\/code> operation returns<\/em> an Element?<\/code>.\nFor a sequence of noncopyable elements, this operation could only\nbe implemented by consuming the elements of the iterated sequence,\nwith the for<\/code> loop taking ownership of the elements individually.<\/p>\n

While consuming iteration is sometimes what you want, borrowing<\/em> iteration is\nequally important, serves as a better default for noncopyable elements,\nand yet cannot be supported by the existing Sequence<\/code>.<\/p>\n

[…]<\/p>\n

Instead of offering up individual elements via next()<\/code> as IteratorProtocol<\/code> does,\nBorrowingIteratorProtocol<\/code> offers up spans of elements. The iterator indicates there\nare no more elements to iterate by returning an empty Span<\/code>.<\/p>\n

[…]<\/p>\n

Note that in the case of Array<\/code>, the new protocol results in much less overhead\nfor the optimizer to eliminate. Iterating a Span<\/code> in the inner loop is a lot\ncloser to the “ideal” model of advancing a pointer over a buffer and accessing\nthe elements directly. It is therefore expected that this design will result\nin better performance in some cases where today the optimizer is unable\nto eliminate the overhead of Swift’s Array<\/code>.<\/p>\n

[…]<\/p>\n

For this reason, it may not be appropriate to switch all for<\/code> iteration to use\nBorrowingSequence<\/code> when Sequence<\/code> is available. How to determine which cases are\nbetter (such as Array<\/code> is expected to be) and which are worse (such as the UnfoldSequence<\/code>\nexample above) needs further investigation. […] For now, if a Sequence<\/code> conformance is available, it will be used\neven if BorrowingSequence<\/code> is also available.<\/p>\n<\/blockquote>\n\n

I haven’t had a need for noncopyable types, but I’m interested in reducing ARC overhead when traversing objects. Most of the time I don’t actually need to retain and release an object just to look at it briefly because I know that it’s not going to be removed from the collection.<\/p>\n\n

Previously:<\/p>\n