# SE-0558: Bulk update operations for \`MutableSpan\` and \`MutableRawSpan\` **URL:** \ **Category:** Proposal Reviews\ **Created:** [October 14, 2026, 1:20am UTC](https://forums.swift.org/t/se-0558-bulk-update-operations-for-mutablespan-and-mutablerawspan/90048 "2026-10-14T01:20:03Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [October 14, 2026, 1:20am UTC](https://forums.swift.org/t/se-0558-bulk-update-operations-for-mutablespan-and-mutablerawspan/90048/1 "2026-10-14T01:20:03Z")
Hi everyone. The review of [SE-0558, Bulk update operations for `MutableSpan` and `MutableRawSpan`](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0558-mutablespan-bulk-updates.md), begins now and runs through **October 28, 2026**. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager via the forum messaging feature. When contacting the review manager directly, please keep the proposal link at the top of the message. #### **What goes into a review?** The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review: - What is your evaluation of the proposal? - Is the problem being addressed significant enough to warrant a change to Swift? - Does this proposal fit well with the feel and direction of Swift? - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? More information about the Swift evolution process is available [here](https://github.com/swiftlang/swift-evolution/blob/main/process.md). Thanks for taking the time to contribute to Swift's evolution! Joe Groff Review Manager ---
**Author:** ![glessard](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/glessard/32/409_2.png) [@glessard](https://forums.swift.org/u/glessard)\ **Post date:** [October 14, 2026, 9:40am UTC](https://forums.swift.org/t/se-0558-bulk-update-operations-for-mutablespan-and-mutablerawspan/90048/2 "2026-10-14T09:40:33Z")
In the pitch thread, Xiaodi [suggested](https://forums.swift.org/t/pitch-bulk-update-operations-for-mutablespan-and-mutablerawspan/89843/5) using the argument label `startingAt` for the first argument of the `updateElements()` functions. I think that is an improvement over the `from` label in the proposal, and would be interested in others's opinions over this. The first example from the proposal involving `Iterable` would become: ```swift var destination = array.mutableSpan var index = 0 destination.updateElements(startingAt: &index, copying: header) destination.updateElements(startingAt: &index, copying: payload) destination.updateElements(startingAt: &index, copying: checksum) precondition(index == destination.count) ``` This label would also work for a `nextSpan()` function for a piecewise-contiguous container: ```swift func nextSpan(startingAt: &index, maxCount: Int) ``` ---
**Author:** ![glessard](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/glessard/32/409_2.png) [@glessard](https://forums.swift.org/u/glessard)\ **Post date:** [October 14, 2026, 9:58am UTC](https://forums.swift.org/t/se-0558-bulk-update-operations-for-mutablespan-and-mutablerawspan/90048/3 "2026-10-14T09:58:05Z")
@lorentey pointed out that the `updateElements` functions that take an `Iterable` may be undesirable due to their tendency to trap. A better shape would be to allow them to return the final state of their borrowing iterator when the function ends, but the current state of the language then would leave no way to provide the convenience overload that returns an index, since we can't return a tuple that includes a nonescapable type at the moment. Options: - include only the overload that takes an `inout Index` and an `inout BorrowingIteratorProtocol`. - return the final state of the `BorrowingIteratorProtocol` instance from the overload that takes an `inout Index` and a `borrowing some Iterable`, and omit the convenience `throws(Never)` overload. (We would likely want to keep the option to introduce the `throws(Never)` overload in a form that returns a tuple.) The second of these seems fine to me. A thrown error comes from the iterator (by definition), and the iterator state is not useful after an error is thrown. Given that, having an error-or-iterator disjunction seems acceptable. In either case the index is updated, providing required information about the last element updated. ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [November 3, 2026, 11:15pm UTC](https://forums.swift.org/t/se-0558-bulk-update-operations-for-mutablespan-and-mutablerawspan/90048/4 "2026-11-03T23:15:37Z")
I like the current design of those operations. If you just take an iterable value, the span has to have space for all of the values it vends ("copy all of"). It seems reasonably likely that clients can safely establish this precondition before the call, and I wouldn't want to burden them with an iterator result that they can only assert is empty. If you want to only take as many elements as you have space for, you can use the iterator API instead ("copy as many as there's space for"), and then you naturally still have the iterator after it's been partially drained. I do think these are semantically different operations that should be distinguished in source. Currently (with your modification above) they're both just `updateElements(startingAt:copying:)`; it feels like that second argument label should be more precise on one or the other of these.