<div dir="ltr">(By the way, I re-read the quoted part of your message, and I realized the question I posed sounded like a rhetorical question. That wasn't my intent. I'm sorry about that, and I appreciate you explaining why non-contiguous data buffers have been important for certain use cases.)<div><br></div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 10:47 AM, Austin Zheng <span dir="ltr"><<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is good to know, thanks! I will look into dispatch_data_t's implementation more closely; I didn't know it was bridged to NSData.<div><br></div><div>I completely agree that if there are no requirements for a contiguous buffer, then there should be no requirement to implement a Data object as a contiguous buffer. There is nothing about the Collection abstraction that requires a contiguous buffer, anyways.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Austin</div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, May 11, 2016 at 10:33 AM, Zach Waldowski via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><u></u>
<div><span><div>On Wed, May 11, 2016, at 11:38 AM, Austin Zheng via swift-evolution wrote:<br></div>
<blockquote type="cite"><div>One question that this brings up is whether supporting non-contiguous data regions in a native Swift data type is worth the complexity costs. There are good reasons for dispatch_data_t to be implemented the way it is, but NSData has always assumed that it is modeling a contiguous area in memory, and it provides users with raw access to the underlying buffer. A cursory examination of a few other languages (Java, Python, Haskell) show that these languages all model binary data as some sort of contiguous array-like construct containing bytes.<br></div>
</blockquote><div style="font-family:Arial"> <br></div>
</span><div style="font-family:Arial">I do not find this convincing.<br></div>
<div style="font-family:Arial"> <br></div>
<div style="font-family:Arial">NSData has not "always assumed" this; that it is transparently bridged with dispatch_data_t on Darwin contradicts that directly.<br></div>
<div style="font-family:Arial"> <br></div>
<div style="font-family:Arial">It would be prohibitive on efficiency to have to use the lowest-common-denominator of contiguous bytes to be useful in Swift. XPC and NSURLSession, among others, both use dispatch_data_t via NSData to efficiently push large buffers across process boundaries.<br></div>
<div style="font-family:Arial"> </div>
<div style="font-family:Arial">That there are complexities involved should not be reason to not address them. It's 2016 and we don't always deal with buffers of a conveniently small size, just like we don't deal with Strings that are conveniently UTF-8. If sufficiently small buffers are the only thing being addressed for ease, then I don't find the described API that much more valuable than [UInt8] and UnsafeBufferPointer.<br></div>
<div style="font-family:Arial"> </div>
<div style="font-family:Arial">Another language having represented it a certain way does not make it foregone how Swift must do it. Other languages also lack value types, Unicode-correct strings, or memory safety. Swift is living proof that doing things the way C or Java did is not the automatic solution.<br></div>
<div style="font-family:Arial"> <br></div>
<div><div>Zachary Waldowski<br></div>
<div><a href="mailto:zach@waldowski.me" target="_blank">zach@waldowski.me</a><br></div>
</div>
<div> <br></div>
</div>
<br></div></div><span class="">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>