> On Sep 29, 2017, at 1:23 PM, Taylor Swift <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
