Hi Patrick, Thanks for your feedback!
dispatch_data_t certainly is an intriguing alternative. I don't think it would be a good fit for a Swift standard library type verbatim, given that it's written in C and contains APIs that would not really be relevant within a Swift environment, but it should definitely be considered as a model. 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 think, at the very least, overlays should exist to provide initializers that convert between dispatch_data_t in Swift's libdispatch, the native Data type, and NSData (if NSData is still to be a separate type after Data is implemented). If contiguity is not important (and there is no compelling reason for access to raw pointers to be exposed in a public interface), it makes a lot of sense to 'unify' the various data types under a DataProtocol protocol that inherits from RandomAccessCollection. Another question is how a Data type's API will interact with however Swift eventually decides to handle native serialization/deserialization, but that's almost certainly a >= Swift 4 topic and I won't go into detail right now. Austin > On May 11, 2016, at 3:57 AM, Patrick Smith <pgwsm...@gmail.com> wrote: > > Hi Austin, > > The proposal looks well fleshed out! Another alternative to consider is the > ‘DispatchData’ struct from libdispatch currently being reviewed? Some of > additions these could be added as an extension to that type? Or perhaps a > protocol could be made ‘DataProtocol’, that has a base set of required > methods and a further set of extensions using that base. Then NSData and > DispatchData can conform and implement those base methods and each get the > functionality. But personally I think it would be nice to make DispatchData > the native Swift data type, whether the libdispatch team would accept > extensions in the future like this I don’t know, but I think it would be > interesting. > > Patrick > > >> On 11 May 2016, at 7:37 PM, Austin Zheng via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Hello swift-evolution, >> >> I've been thinking about a standard library 'Data' type for a while, >> analogous to NSData in the same way Swift's Arrays and Dictionaries are >> analogous to NSArrays and NSDictionaries. A first-class container for binary >> data that is available to every Swift user, conforms to Swift semantics, and >> is safer and easier to work with than UnsafeBufferPointer seems like a >> natural fit for the standard library. >> >> As such, I've put together a very preliminary proposal, which can be found >> here: >> https://github.com/austinzheng/swift-evolution/blob/d2/proposals/XXXX-stdlib-data.md >> >> <https://github.com/austinzheng/swift-evolution/blob/d2/proposals/XXXX-stdlib-data.md>. >> I present it not as a way to impose a vision of what such a Data type >> should look like, but rather as a way to catalyze discussion (including >> discussion as to whether or not a Data type is even a good idea in the first >> place). >> >> Some thoughts: >> >> - It's not clear if the methods to convert to and from base-64 encoded data >> are necessary. The state flag that tries to mark whether or not a Data >> represents base-64-encoded string stored as a data may be unnecessary as >> well. >> >> - I didn't really go into how NSData should be bridged. Special >> consideration needs to be given to how any native Data type would interact >> with the overlays described in >> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md >> >> <https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md>. >> It's possible (and only if a compelling technical reason exists) that the >> Foundation implementation of NSData can in the future be moved into >> Swift/supplanted by such a native data type, with API extensions to provide >> conformance to the Objective-C Foundation API. This proposal should not be >> seen as an attempt to usurp Foundation's job, though - there are plenty of >> to-be-value types in Foundation whose inclusion directly in the standard >> library makes little sense. >> >> - Perhaps Data should be generic over various types of fixed-width integers >> (signed and unsigned, 8, 16, 32, 64, machine-width, etc). In that case it >> might also provide generic views (for example, to allow iteration over a >> Data<UInt64> as if it were a collection of UInt8 bytes). I'm not yet sure if >> this is feasible or desirable. >> >> Finally, it's possible that this is strictly Swift 4 territory, in which >> case I'm happy to withdraw from discussion until the time is right later >> this year. >> >> Best regards, >> Austin >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto: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
