<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><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;">&nbsp;<br></div>
<div style="font-family:Arial;">I do not find this convincing.<br></div>
<div style="font-family:Arial;">&nbsp;<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;">&nbsp;<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;">&nbsp;</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;">&nbsp;</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;">&nbsp;<br></div>
<div id="sig40804545"><div class="signature">Zachary Waldowski<br></div>
<div class="signature"><a href="mailto:zach@waldowski.me">zach@waldowski.me</a><br></div>
</div>
<div>&nbsp;<br></div>
</body>
</html>