[swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

[Tony Parker]

Hi Karl,

> On Apr 22, 2017, at 6:23 AM, Karl Wagner <razielim at gmail.com> wrote:
> 
>> 
>> On 20 Apr 2017, at 19:08, Tony Parker via swift-evolution <swift-evolution at swift.org <mailto: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.
>> 
>> Thanks,
>> - 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.
> 

We’re aware of this, but it’s something I’d like to tackle separately from the Coding proposals.

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

We considered something along these lines:

    func encode<T : Encodable>(_ value: T?, ...) // existing
    func encode<T : RangeRepleaceableCollection>(_ value: T?, ...) where T.Iterator.Element == UInt8

but this is ambiguous when we have conditional conformance and Array where Element : Encodable is Encodable. Did you mean to encode base64-encoded data for JSON or an array of UInt8? Data resolves the ambiguity by assigning more meaning to a Collection of UInt8.

We could resolve the ambiguity by using a different name (like you suggest above), but this reduces the viability of Data as a common currency type, which we believe is very important. Ultimately we felt that going with one less primitive here was a better approach.

- Tony

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170424/4e5b98a5/attachment.html>