[swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization
razielim at gmail.com
Sat Apr 22 08:23:20 CDT 2017
> On 20 Apr 2017, at 19:08, Tony Parker via swift-evolution <swift-evolution at swift.org> wrote:
> Hi everyone,
> Thanks for your feedback on this proposal. Based on that plus additional feedback from core team members and others who responded off-thread, we are making the following small adjustments:
> * KeyedEncoderContainerProtocol, KeyedDecodingContainerProtocol, UnkeyedEncodingContainer, UnkeyedDecodingContainer, SingleValueEncodingContainer, SingleValueDecodingContainer will drop their Data-taking functions. Data will conform to Codable, so it just goes through the normal paths like other types.
> * The above will allow those protocols, plus Encodable, Decodable, typealias Codable, Encoder, Decoder, CodingKey, struct CodingUserInfoKey to be part of the standard library (not in Foundation), resolving the concern about reaching too far up the stack for the compiler.
> * JSONEncoder/Decoder, PropertyListEncoder/Decoder remain in Foundation. These are concrete implementations of the above protocols, like the ones that will appear in many libraries, we hope.
> We are not currently proposing using the integer protocols. The reasoning is that using them them confers a requirement upon all possible encoders and decoders to support arbitrary-width integers and floating point values. We’re not convinced this is feasible, but we will continue to evaluate.
> If the core team accepts the modified proposal, we will get this merged as soon as possible with the goal of allowing all of you to try everything out via Swift’s frequent toolchain snapshots. We will be looking for feedback on how it works in more real world scenarios, and we will consider further adjustments to the API before Swift 4 is final. We are hoping that this extended trial period will allow us to make sure that everything works out the way we expected.
> - Tony
That’s a great step; thanks a lot!
As for Data/UnsafeRawBufferPointer (beyond this proposal): I agree that a Data object which owns its buffer should be the common-currency for passing buffers around, but I also think that the standard library should own that “Data” type. Data is (IMO), no less "primitive” than, say, Array, Dictionary, Set and String - yet while all of those types are part of the standard library, Data lives much further down the stack, in Foundation. The standard library is limited to unsafe buffers, without a “safe” alternative. Even though Foundation is a core library and very useful, it is still an optional component of any Swift installation or application, and I feel it’s not unreasonable to ask for a safe buffer without that dependency.
I could of course define my own RAII, UnsafeRawBufferPointer-wrapping “Data” type, but then it either spreads throughout my API and undermines Data as a common currency, or I need to convert it (with a copy, in order to preserve value semantics). This is the same issue that affects DispatchData/Data bridging, which in that case undermines APIs such as DispatchIO; either all of my APIs now take a DispatchData (leaking implementation details), or I have to copy the buffer in to a Foundation Data.
That’s an issue which I would like to help solve more comprehensively one day, but for the mean time:
1) Is untyped data really a “primitive” in the context of serialisation? If so...
2) Why are we removing it? Is it only because the standard library lacks a good type to represent the data? If so...
3) Why not introduce a generic function?
mutating func encodeBytes<C>(_ bytes: C, forKey key: Key) throws where C: Collection, C.Element == UInt8
This single function would be able to encode Data, DispatchData, UnsafeRawBufferPointer, and even an Array<UInt8>.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution