[swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

[Nate Cook]

> On Dec 2, 2016, at 2:12 PM, Ben Cohen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 3) Make all buffer pointers their own slices but use a different index type. If the indices were just wrapped pointers, that would handle the index sharing without needing an additional property on the buffer. We could also maintain integer-based stridable conformance (which greatly simplifies index arithmetic), since the indices would just offset by a byte for raw buffers or a stride for typed buffers.
>> 
> 
> Unfortunately, switching to non-integer indices would change this from being mildly source-breaking to being extremely source-breaking, as there’s lots of code out there using buffers today indexing them with integers (including integer literals).
> 
> The big win with UnsafeBufferPointer having an integer index is it’s a drop-in replacement for arrays, so when you hit a performance problem using an array you can quickly switch to using a buffer under most circumstances instead without having to change much of your code – including code that uses for i in 0..<myArray.count, of which there is a lot out there in the wild. Switching to an opaque index would break anyone doing that.

It is definitely very source-breaking, though with relatively simple fixits:

	buf[0] ---> buf[buf.startIndex]
	buf[3] ---> buf[buf.startIndex + 3]
	buf[i] ---> buf[buf.startIndex + i]

Any integer arithmetic happening outside the subscript could be left unchanged. If that cost isn't worth the benefit, then making UnsafeRawBufferPointer use Slice as its slice type is probably the best way to resolve that issue.

Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161202/774826cc/attachment.html>