on Thu Dec 01 2016, Jordan Rose <swift-evolution@swift.org> wrote: >> 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.
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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
