Make move/assign/initialize easier on buffer pointers

[nnnnnnnn (Nate Cook)]

In this thread, it's come up that UnsafeMutableBufferPointer doesn't have all the operations that you can perform with a direct UnsafeMutablePointer. You need to drop down to a pointer to move instances from memory or initialize a single instance — the subscripting interface only supports assignment.

The way I see it, there are two reasonable approaches here:

1. Provide a way to access an UnsafeMutablePointer at a specific offset, and then use that type's existing APIs to manipulate the memory at that location. For example:

   myBuffer.pointer(at: 5).initialize(to: 100)
   

2. Copy the APIs that are on UnsafeMutablePointer up to the buffer pointer, with the index as an argument:

   myBuffer.initialize(to: 100, at: 5)
   

Thoughts? I don't have a major preference between those two — they're each simpler and more complex than the other in different ways.

[taylorswift]

we should probably dig up the old SE-184 threads, they had reams of discussion about this feature

[taylorswift]

should probably read through these:

SE-184 Improved Pointers

Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is ready for community review, and I encourage everyone to look it over and provide feedback. Thank you! < https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md

···

SE-1084 (B): buffer pointer partial initialization API

Hi guys, after passing SE 184 (A) <https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md&gt;, I want to get some community feedback on the next phase of our Swift pointer overhaul which is a partial initialization/deinitialization API for UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer. You can read about the originally proposed API in the original SE 184 document <https://github.com/apple/swift-evolution/blob/master/proposals/0184…

Pitch: Improved Swift pointers

Hi all, I’ve written up a proposal to modify the unsafe pointer API for greater consistency, safety, and ease of use.

···

~~~ Swift currently offers two sets of pointer types — singular pointers such as UnsafeMutablePointer, and vector (buffer) pointers such as UnsafeMutable *Buffer*Pointer. This implies a natural separation of tasks the two kinds of pointers are meant to do. For example, buffer pointers implement Collection conformance, while singular pointers do not. However, some aspec…

the name of the feature you’re talking about was called memorystate APIs during the review of SE-184, this is a draft of it but it had major problems so it was dropped from SE-184

[nnnnnnnn (Nate Cook)]

Thanks for those links! The fifth and seventh bullets from the "Proposed Solution" section of that proposal draft are essentially the #2 option of my opening question. Do you remember if there were specific problems with that approach, or if those memorystate methods were cut to keep the focus of the proposal smaller?

[taylorswift]

@nnnnnnnn

Thanks for those links! The fifth and seventh bullets from the "Proposed Solution" section of that proposal draft are essentially the #2 option of my opening question. Do you remember if there were specific problems with that approach, or if those memorystate methods were cut to keep the focus of the proposal smaller?

honestly i cut it because it was causing a lot of drama and holding up the rest of the proposal. i think the main problem revolved around there being two potentially contradicting count parameters when you have two UnsafeBufferPointers, since all the memorystate functions (except deinitialize) are binary operations. if you generalize the API to take an explicit count: argument, then you have 3 potentially contradicting count parameters. so yeah

also not the same as this feature but definitely related and was supposed to be making its rounds around the same time as this: Back to deallocate(capacity:) — advanced heap allocation