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

[Austin Zheng]

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 <pgwsmith at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto: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/86cc23a5/attachment.html>