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. 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).
- 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. 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.