[swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers
Dave Abrahams
dabrahams at apple.com
Thu Dec 1 13:30:42 CST 2016
on Thu Dec 01 2016, Jordan Rose <swift-evolution at swift.org> wrote:
>> On Nov 30, 2016, at 16:15, Dave Abrahams via swift-evolution
> <swift-evolution at swift.org> wrote:
>>
>>
>> on Wed Nov 30 2016, Kevin Ballard
>> <swift-evolution at swift.org
>
>> <mailto:swift-evolution at swift.org>>
>> wrote:
>>
>>> This sounds like a sensible idea. But there is one behavioral change you
>>> haven't addressed, which is that this changes how indexes work on the
>>> slice. With all other slice types that come to mind, the slice shares
>>> the same indexes as the base, e.g.
>>>
>>> let ary = Array(0..<10)
>>>
>>> print(ary[3]) // prints 3
>>>
>>> print(ary[2..<5][3]) // still prints 3
>>
>> This is an important invariant that we need to maintain.
>>
>>> UnsafeBufferPointer is indexed using 0-based integers, so with your
>>> proposal, slicing an UnsafeBufferPointer produces a value that uses
>>> different indexes. We could solve this by adding a new field, but that
>>> would break the expectation that startIndex is always zero.
>>
>> I'm not sure that's an expectation we're obligated to honor. Of course,
>> once you get into “unsafe” territory like this, breaking even the
>> expectations that aren't based on documented guarantees can be really
>> dangerous.
>>
>> We probably ought to have wrapped those integers in some Index type
>> specific to UnsafeBufferPointer, so zero wasn't even a value.
>
> Since UnsafeBufferPointer is like an Array, I think it is supposed to
> have integer indexes from the start of the buffer.
I'm not sure it's important that the indices be integers. Once we get
into this unsafe corner of the language, it might be better if they
weren't.
--
-Dave
More information about the swift-evolution
mailing list