> On Nov 30, 2016, at 16:15, Dave Abrahams via swift-evolution
> <firstname.lastname@example.org> wrote:
> on Wed Nov 30 2016, Kevin Ballard <email@example.com
> <mailto:firstname.lastname@example.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) // prints 3
>> print(ary[2..<5]) // 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
> 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
swift-evolution mailing list