[swift-evolution] Standard library 'Data' type pre-proposal

[Zach Waldowski]

On Wed, May 11, 2016, at 11:38 AM, Austin Zheng via swift-evolution wrote:
> 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.
 
I do not find this convincing.
 
NSData has not "always assumed" this; that it is transparently bridged
with dispatch_data_t on Darwin contradicts that directly.
 
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.
 
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.
 
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.
 
Zachary Waldowski
zach at waldowski.me
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160511/04038d85/attachment.html>