(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 <[email protected]> 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 < > [email protected]> 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 >> [email protected] >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
