[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

[Ben Cohen]

> On Sep 29, 2017, at 1:23 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
> 
> 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. 
> 
> Using Sequences throws out a whole host of assumptions we’ve been taking advantage of. We can’t check for source.count anymore since that requires traversing the entire Sequence.

Sequence provides underestimatedCount. In the case of unsafe buffer types, underestimatedCount just gives the count. A requirement of initialize(from: source) is that the caller must provide at least enough room for the underestimatedCount.

> And if the performance is so bad relative to the UnsafePointer API, we have to ask what the purpose of such a buffer API would even be. 

It shouldn’t be much different, performance-wise. initialize(from:) bounces directly into a call to source._copyContents(initializing:), which can be specialized to perform lower-level memory copying operations (as it is already for types like array). The optimizer needs to ensure that this is just as efficient as if we had an initialize that took an unsafe buffer. It ought to do this already, but if not, the implementation of this SE should include making sure it does. As a last resort, we could add concrete overloads for buffers – but bear in mind, you want at least to be able to initialize from 1) an UnsafeBufferPointer, 2) an UnsafeMutableBufferPointer, and 3) slices of 1 and 2. This would probably mean we need some kind of generic method regardless.

> The whole purpose of the buffer API was to make it easier to do things with pointers without having to keep track of buffer lengths externally. It should be built around the UnsafePointer API, not the much higher level Sequence API.
>  

This would come at a cost of essentially duplicating API surface area for both concrete and generic source. This should only be done for very good reasons, and performance issues that can be resolved as part of the implementation aren’t necessarily a sufficient one.


> 
> 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
> 
> 

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