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

[David Hart]

> On 12 Apr 2017, at 20:44, Russ Bishop via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0166 "Swift Archival & Serialization" begins now and runs through April 12, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md <https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md>
>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md <https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md>
>> Reply text
>> Other replies
>>  <https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>> 
>> What is your evaluation of the proposal?
> It is a good first step but I feel like it tries to match NSSecureCoding design patterns too strongly and introduces a lot of potential for API misuse (convention rather than using the type system to our advantage). If we ask "what does a modern take on NSSecureCoding look like?", this proposal is the answer. If we ask "how can we do better than NSSecureCoding?" then this proposal needs a little bit of refinement.

I also agree that the API feels slightly more influenced by NSCoding and Objective-C paradigms than by Swift idioms.

> Some examples:
> 
> * String and Int keys being optional, giving a CodingKey the opportunity to return nil for both at runtime.
> * Encoder has three functions, but only one may ever be called. This API is the opposite of "pit of success”.

The amount of preconditions in the documentation of Coder and then CocoaError.coderTypeMismatch errors of Decoder paint the same picture. I understand the argument that writing this proposal taking full advantage of the type system would exponentially increase the number of types and worsen the API. But perhaps the Encoder/Decoder protocols could take advantage of more types.

> There is also the problem of an implementation cliff: A type that has one non-Encodable property suddenly needs to provide a complete implementation. It is relatively common to have ephemeral data you don't even want to be encoded but again it seems like you need to jump immediately to a completely manual solution.

I don’t think you’re right here. The proposal states:

	• Types falling into (1) — and types which manually provide a CodingKey enum (named CodingKeys, directly, or via a typealias) whose cases map 1-to-1 to Encodable/Decodable properties by name — get automatic synthesis of init(from:) and encode(to:) as appropriate, using those properties and keys

So if you do have ephemeral data, you’d only need to define the CodingKey enum and be good to go.

> There may not be a way to square this circle but it is worth thinking about. One improvement would be that a type can provide its own CodingKey but still get automatic conformance for all properties that match. At least then you would have a way to filter out the properties you don't want.
> 
> 
> I don't understand why KeyedEncodingContainer needs all those overloads; automatic conformance to Encodable should be provided for the stdlib types in those overloads so why would they be necessary?

I’ve been beating the same bush. I know the arguments but it just feels wrong to me. That’s a case where this API definitely feels more like Objective-C than Swift.

> KeyedEncodingContainer.encodeWeak seems like it should be a protocol refinement so you can check for the capability (or potentially know at compile time).  The decoder begs a similar question: why not rely on the generic functions? (One minor bit of bike shedding: decode/decodeIfPresent could instead be decode(required:) and decode(optional:)).
> 
> 
> I really strongly dislike mixing up the Unkeyed and Keyed concepts. A type should need to explicitly opt-in to supporting unkeyed and that should be enforced at compile time. Unkeyed encoding is a potential versioning nightmare and should be handled with care.
> 
> 
>> Is the problem being addressed significant enough to warrant a change to Swift?
> Definitely yes.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> See comments above
> 
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> Yes; C#'s serialization attributes are a better and more comprehensive solution but we don't have custom attributes in Swift and property behaviors were deferred. This problem is too important to leave to the future though. If we did ever add custom attributes or if property behaviors get implemented then this design could adopt them incrementally without breaking compatibility (e.g. a serialization transformer behavior that turns a non-Encodable property into an Encodable one, or a behavior that ignores a property for serialization purposes).
> 
> 
> 
> I want to say thank-you to Itai, Michael, and Tony for their hard work on this and the related proposal; having done a proposal myself I know how much work it entails.
> 
> 
> Russ Bishop
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170412/f3dc5184/attachment-0001.html>