<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Patrick,<div class=""><br class=""></div><div class="">Thanks for your feedback!</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Austin</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 11, 2016, at 3:57 AM, Patrick Smith <<a href="mailto:pgwsmith@gmail.com" class="">pgwsmith@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Austin,</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Patrick</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 11 May 2016, at 7:37 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello swift-evolution,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">As such, I've put together a very preliminary proposal, which can be found here: <a href="https://github.com/austinzheng/swift-evolution/blob/d2/proposals/XXXX-stdlib-data.md" class="">https://github.com/austinzheng/swift-evolution/blob/d2/proposals/XXXX-stdlib-data.md</a>. 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).</div><div class=""><br class=""></div><div class="">Some thoughts:</div><div class=""><br class=""></div><div class="">- 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.</div><div class=""><br class=""></div><div class="">- 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 <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md</a>. 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.</div><div class=""><br class=""></div><div class="">- 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Best regards,</div><div class="">Austin</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></body></html>