> On Nov 30, 2016, at 16:15, Dave Abrahams via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> on Wed Nov 30 2016, Kevin Ballard <swift-evolution@swift.org 
> <mailto:swift-evolution@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. (It's what we're telling people 
to use as the currency type for what would be pointer/size pairs in C.) So I 
think Kevin's point is valid, and UnsafeBufferPointer cannot be its own slice 
type.

Jordan

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to