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