[Pitch] Safe Access to Contiguous Storage

[Karl]

I'm also not thrilled about the name "storage view". I think that name has connotations which are not always accurate - developers may wish to expose lexically-scoped buffers in their APIs for a variety of reasons.

For instance, perhaps I want to stream the bytes of a file, giving a closure temporary access to a stack-allocated buffer:

struct File {
  func stream(_ processBytes: (StorageView<UInt8>) -> Void)
}

And I've mentioned previously that if we had generator functions in the language, one could even imagine an async iterator using this pattern.

@Karl

And then you'd write your iterator like so:

mutating func next<T>(
  _ yield: ([UInt8]) async throws(T) -> IterationResult
) async throws(errorUnion(Failure, T)) {

  var buffer = [UInt8]()
  while await populateBuffer(&buffer) {
    guard try await yield(buffer) == .continue else { break }
  }
}

And now that we're yielding borrows of the element rather than returning copies of it, the element can instead be a non-copyable type -- and even a non-escaping type like some kind of stack buffer.

And so if we imagine some kind of File.ChunkedBytesGenerator (or whatever you want to call it), its associated Element type would be called StorageView. But those values don't represent the storage of the file or the bytes generator. It's not really storage of anything that you'd care about; it's just a non-escapable buffer.

I also think the name is unnecessarily scary/low-level. If this is a safe type, we should give it a nicer name. I think the term "array" is friendlier for Swift developers than "buffer", so I'd suggest something along the lines of SharedArray, NonOwnedArray (or maybe even "unowned"), or BorrowedArray.

I have more to say about this (in particular the idea of a ContiguousStorage protocol - I don't love it), but for now I wanted to mention something about the name.