> On Nov 6, 2016, at 1:20 PM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > > Given that we're headed for ABI (and thus stdlib API) stability, I've > been giving lots of thought to the bottom layer of our collection > abstraction and how it may limit our potential for efficiency. In > particular, I want to keep the door open for optimizations that work on > contiguous memory regions. Every cache-friendly data structure, even if > it is not an array, contains contiguous memory regions over which > operations can often be vectorized, that should define boundaries for > parallelism, etc. Throughout Cocoa you can find patterns designed to > exploit this fact when possible (NSFastEnumeration). Posix I/O bottoms > out in readv/writev, and MPI datatypes essentially boil down to > identifying the contiguous parts of data structures. My point is that > this is an important class of optimization, with numerous real-world > examples. > > If you think about what it means to build APIs for contiguous memory > into abstractions like Sequence or Collection, at least without > penalizing the lowest-level code, it means exposing UnsafeBufferPointers > as a first-class part of the protocols, which is really > unappealing... unless you consider that *borrowed* UnsafeBufferPointers > can be made safe. > > [Well, it's slightly more complicated than that because > UnsafeBufferPointer is designed to bypass bounds checking in release > builds, and to ensure safety you'd need a BoundsCheckedBuffer—or > something—that checks bounds unconditionally... but] the point remains > that > > A thing that is unsafe when it's arbitrarily copied can become safe if > you ensure that it's only borrowed (in accordance with well-understood > lifetime rules).
UnsafeBufferPointer today is a copyable type. Having a borrowed value doesn't prevent you from making your own copy, which could then escape the scope that was guaranteeing safety. This is fixable, of course, but it's a more significant change to the type and how it would be used. John. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
