> 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 > 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 email@example.com https://lists.swift.org/mailman/listinfo/swift-evolution