Make move/assign/initialize easier on buffer pointers

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.

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

should probably read through these:

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

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