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

[Tony Parker]

Hi Brent,


> On Apr 20, 2017, at 11:37 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> On Apr 20, 2017, at 10:08 AM, Tony Parker via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> * 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.
> 
> I think this is a huge win for Swift and a great move, but...
> 
>> * 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.
> 
> 
> ...I hope the `Data`-taking primitive will not be deleted, but rather replaced by one that takes `UnsafeRawBufferPointer` or some similar standard library representation of a byte sequence. Even if it has to be called `encodeBytes` and `decodeBytes` to clarify that it's not somehow coding a pointer, I think a series of bytes truly *is* a primitive type, and something fairly distinct from an unkeyed container of `UInt8`s.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

We still believe the right representation for the majority of data use cases is Data. UnsafeRawBufferPointer is not really the same thing, because (a) it’s unsafe, and (b) it has different mutation characteristics than CoW Data. In any case, this change encourages each encoder to decide for itself how to handle specific types if they make sense for that format. For example, JSONEncoder will switch on the type of the Encodable thing passed to it and do something different if it’s Data. It puts Data in the same bucket as things like Date and URL as types that some coders may just want to treat specially.

It may be reasonable for the *BufferPointer APIs to adopt Codable themselves now. They could encode themselves as [UInt8] by default. Concrete encoders (like JSONEncoder) could switch on the type to do something special if they want, like base64 encoding them. We could easily propose that as an addition to this if we think it’s valuable.

One more thing, which we realized after I sent my original email: the default implementation of many of the protocols needs to throw errors. Therefore we will add enum EncodingError and enum DecodingError to the list of new types. Those enums will have various associated values according to what is useful debug information. To preserve the ability for developers to present these errors to users with localized and user-presentable messages, when these enums are cast to NSError (e as? NSError), they will have the Cocoa error domain and a Foundation-provided code. (This is done via an extension to the enum in Foundation).

- Tony

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170421/0ac5e4ca/attachment.html>