on Mon Nov 07 2016, John McCall <[email protected]> wrote: >> 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.
It sounds like you're saying that, to get static safety benefits from ownership, we'll need a whole parallel universe of safe move-only types. Seems a cryin' shame. -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
