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

[Austin Zheng]

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.

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.

Austin

On Wed, May 11, 2016 at 10:33 AM, Zach Waldowski via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160511/f5dde866/attachment.html>