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

[Austin Zheng]

(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.)

Austin

On Wed, May 11, 2016 at 10:47 AM, Austin Zheng <austinzheng at gmail.com>
wrote:

> 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/90f0424b/attachment.html>