[swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

[Dave Abrahams]

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).

And this leads me to wonder about our practice of embedding the word
"unsafe" in names.  A construct that is only conditionally unsafe
shouldn't be spelled "unsafe" when used in a safe way, right?  So this
*seems* to argue for an "unsafe" keyword that can be used to label
the constructs that actually add unsafety (as has been previously
suggested on this list).  Other ideas are of course most welcome.

-- 
-Dave