SE-0467: MutableSpan

Evolution Proposal Reviews
1

Hi everyone. The review of SE-0467: MutableSpan begins now and runs through March 25, 2025.

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.

Trying it out

If you'd like to try this proposal out, you can download a toolchain supporting it:

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 at swift-evolution/process.md at main · swiftlang/swift-evolution · GitHub.

Thank you for helping to improve Swift!

Joe Groff
Review Manager

15 Likes
2

Some test toolchains are here:
Ubuntu
Windows
macOS

In these toolchains the mutableSpan properties exist only for Array, ContiguousArray and ArraySlice.

2 Likes
3

The "Detailed design" section (and the implementation) contains:

extension MutableSpan: @unchecked Sendable where Element: Sendable {}

Should the conformance be:

  • unconstrained for noncopyable and nonescapable elements?

    extension MutableSpan: @unchecked Sendable
where Element: Sendable & ~Copyable & ~Escapable {}

  • removed or unavailable — similar to SE-0331 for unsafe pointers?

The "Future directions" section contains an extracting method:

extension MutableSpan where Element: ~Copyable {
  public mutating func extracting(_ bounds: Range<Index>) -> Self
}

which seems identical to the method in the "Proposed solution" and "Detailed design".

1 Like
4

You're correct that the Sendable conformance should be unconstrained.

A Span<UnsafeRawPointer> won't be sendable due to UnsafeRawPointer not being Sendable, so there is no need to do more.

I did forget to remove the "extracting" subsection from "Future Directions." Will fix (fixed).

3 Likes
5

Interesting. In general the proposal makes sense and I don't have any objections.

Would it make sense to augment MutableCollection to automatically provide a mutableSpan property?

1 Like
6

A general collection is not contiguous, and therefore cannot vend a MutableSpan property over its contents. It would be feasible to provide either an optional mutable span (a la withContiguousMutableStorageIfAvailable),¹ or a closure-taking operation, but it likely makes sense to delay designing that to go with a more systematic proposal rethinking collections to account for ~Copyable/~Escapable constraints.

¹ well, it would be possible once Optional supports ~Escapable wrapped types.

4 Likes
7

I'm still holding out hope that we formalize a ContiguousCollection protocol that guarantees this property--then it could provide span by default as well as mutableSpan when & MutableCollection.

(I'm going off on a tangent here, I know!)

1 Like