<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Yes, this is a very important issue to consider before we freeze them.<div class=""><br class=""></div><div class="">As part of my Swift hobby, I have worked a bit on a Swifty wrapper for linear algebra packages and also toyed a bit with the merits of a Swift implementation of some of the related algorithms and data structures (such as banded or sparse matrices)<div class=""><br class=""></div><div class="">It is really difficult to come up with efficient and generic solutions in these spaces. I had a brush with <a href="http://julialang.org" class="">Julia</a> as well. Have you looked at their work and the recent reworking of their similar data structures?</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 6, 2016, at 1:20 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">Given that we're headed for ABI (and thus stdlib API) stability, I've<br class="">been giving lots of thought to the bottom layer of our collection<br class="">abstraction and how it may limit our potential for efficiency. In<br class="">particular, I want to keep the door open for optimizations that work on<br class="">contiguous memory regions. Every cache-friendly data structure, even if<br class="">it is not an array, contains contiguous memory regions over which<br class="">operations can often be vectorized, that should define boundaries for<br class="">parallelism, etc. Throughout Cocoa you can find patterns designed to<br class="">exploit this fact when possible (NSFastEnumeration). Posix I/O bottoms<br class="">out in readv/writev, and MPI datatypes essentially boil down to<br class="">identifying the contiguous parts of data structures. My point is that<br class="">this is an important class of optimization, with numerous real-world<br class="">examples.<br class=""><br class="">If you think about what it means to build APIs for contiguous memory<br class="">into abstractions like Sequence or Collection, at least without<br class="">penalizing the lowest-level code, it means exposing UnsafeBufferPointers<br class="">as a first-class part of the protocols, which is really<br class="">unappealing... unless you consider that *borrowed* UnsafeBufferPointers<br class="">can be made safe. <br class=""><br class="">[Well, it's slightly more complicated than that because<br class="">UnsafeBufferPointer is designed to bypass bounds checking in release<br class="">builds, and to ensure safety you'd need a BoundsCheckedBuffer—or<br class="">something—that checks bounds unconditionally... but] the point remains<br class="">that<br class=""><br class=""> A thing that is unsafe when it's arbitrarily copied can become safe if<br class=""> you ensure that it's only borrowed (in accordance with well-understood<br class=""> lifetime rules).<br class=""><br class="">And this leads me to wonder about our practice of embedding the word<br class="">"unsafe" in names. A construct that is only conditionally unsafe<br class="">shouldn't be spelled "unsafe" when used in a safe way, right? So this<br class="">*seems* to argue for an "unsafe" keyword that can be used to label<br class="">the constructs that actually add unsafety (as has been previously<br class="">suggested on this list). Other ideas are of course most welcome.<br class=""><br class="">-- <br class="">-Dave<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>