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

[Jon Shier]

> What is your evaluation of the proposal?
-1. Like I said in my review of 167, this sort of core API is far too important for the implementation to be so flawed.

* This proposal is extensive. An implementation playground would’ve been nice. Containers seem fairly odd, so it would’ve been nice to see how they feel in use.

* Like 167, this proposal feels very Objective-C like. While we want interoperability with NSCoder and NSKeyedArchiver, this should be a native Swift solution first and a bridge second. Also, some bits of the API aren’t Swifty; any API which uses Type.self just doesn’t feel right. Please, use the generics. 

someString = try container.decode(forKey: .someString) can infer the type from the assignee, no?

* This sort of API works well when the responses are logically formed, but this also forms the basis of the APIs we’ll be using to interact with JSON, which can be anything but logically formed. For instance:

struct Veritas {
    let truth: Bool
} 

Simple, right?

But say it’s JSON representation is this:

{ “some_Bad_key” : “Yes” }

How would this proposal let me transform a Yes string into the proper boolean value? There doesn’t seem to be a solution provided, just the brute force method of trying to decode as a string first and then transforming. Plus, if I have a single value that I need to do something custom to, I need implement init(from decoder:) for my entire type, so it becomes very painful very quickly. I foresee a new collection of open source libraries to remedy this shortcoming, and they really shouldn’t have to.

Also, what if I wanted to be able to decode this type from both the terrible JSON and a nice on disk format? Some way to provide multiple conforming initializers would be nice.

Suffice to say my biggest concern here is that this API is designed for the ideal and not the messy reality of JSON APIs created by the lowest bidder. Since this proposal is supposed to cover both, it needs to offer support for the worst case scenarios more easily.

* The errors generated just aren’t good. I covered this in more detail in my review of 167, but suffice it to say they’re too limited by the desire to bridge them to NSErrors and don’t capture any useful details about what caused them in the first place. Also, they shouldn’t live in Foundation, as this is a feature the standard library will implement. 

> Is the problem being addressed significant enough to warrant a change to Swift?
Yes, this is a problem worth solving, I just don’t think this proposal is good enough.

> Does this proposal fit well with the feel and direction of Swift?
No. Passing types around isn’t Swifty at all. This fits right in in Objective-C though.

> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I’ve been an Argo user for 2 years, so I’m used to a certain terseness and flexibility in my decoders. This proposal brings neither. Argo also has superior errors which capture the keys and types that caused an issue. I guarantee there will be at least one open source library which provides operators that wrap this proposal’s API so that you can properly transform decoded values without multiple lines of code.

> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Multiple read throughs, about an hour of analysis. 



Jon Shier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170413/4202ef8c/attachment.html>