[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

[Andrew Trick]

> 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.countanymore since that requires traversing the entire Sequence. 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. 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.

Those are good points. I’m also somewhat concerned about -Onone performance. Can you point to some code in your library that becomes excessively redundant by specifying the source.count at the call site?

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