[swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

[Karl Wagner]

> On 29. Sep 2017, at 02:59, Andrew Trick via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Sep 6, 2017, at 10:15 PM, Taylor Swift <kelvin13ma at gmail.com <mailto:kelvin13ma at gmail.com>> wrote:
>> 
>> okay so I think so far what’s been agreed on is 
>> 
>> 1. rename “Bytes” to “Memory” in the raw pointer API. Note: this brings the `copyBytes<C>(from:)` collection method into the scope of this proposal
>> 
>> 2. change raw offsets to be in terms of bytes, not typed strides. This argument will be called `atByteOffset:` and will only appear in UnsafeMutableRawBufferPointer. “at:” arguments are no longer needed in UnsafeMutableRawPointer, since we can just use pointer arithmetic now.
>> 
>> 
>> 3. move UnsafeMutableBufferPointer’s `at:` arguments to the front of the parameter list. mostly cause any pointer arithmetic happens in the front so structurally we want to mirror that.
>> 
>> 4. add dual (to:) single element initializers and assigners to UnsafeMutablePointer, but not UnsafeMutableRawPointer because it’s apparently not useful there. `UnsafeMutableRawPointer.initializeMemory<T>(as:repeating:count:)` still loses its default count to prevent confusion with its buffer variant.
>> 
>> 5. memory deallocation on buffer pointers is clearly documented to only be defined behavior when the buffer matches a whole heap block. 
> 
> 
> Kelvin,
> 
> Attempting to limit the scope of this proposal backfired. I was hoping to avoid discussing changes to the slice API, instead providing basic functionality within the buffer API itself. However, Dave Abrahams has argued that once the slice API is extended, the positional arguments are extraneous and less clear.
> 
> Instead of
> 
>   buf.intialize(at: i, from: source)
> 
> We want to force a more obvious idiom:
> 
>   buf[i..<n].intialize(from: source)
> 
> I think this is a reasonable argument and convinced myself that it's possible to extend the slice API. I'm also convinced now that we don't need overloads to handle an UnsafeBufferPointer source, instead we can provide a single generic entry point on both UnsafeMutableBufferPointer and its slice, optimized within the implementation:
> 
>  `initialize<S : Sequence>(from: S) -> (S.Iterator, Index)
> 
> We can always drop down to the UnsafePointer API to get back to a direct unsafe implementation as a temporary workaround for performance issues.
> 
> Let's set aside for now whether we support full or partial initialization/assignment, how to handle moveInitialize, and whether we need to return the Iterator/Index. This is going to require another iteration on swift-evolution, which we should discuss in a separate thread. 
> 
> At this point, I suggest removing the controversial aspects of SE-0184 so that we can put the other changes behind us and focus future discussion around a smaller follow-up proposal.
> 
> Here I've summarized the changes that I think could be accepted as-is:
> https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e <https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e>
> 
> If you amend SE-0184 accordingly and file a new PR, I think it can be quickly approved.
> 
> -Andy
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

So I understand that partial deallocation was never really supported (even if the old API allowed you to write it) but, given that, would it be possible to add reallocation to re-size an already allocated buffer? That’s a pretty glaring hole in the Swift raw-memory API.

- Karl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171002/d4256e37/attachment.html>