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@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 > z...@waldowski.me > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
