> On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution > <swift-evolution@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.
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". 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. 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? 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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
