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

[Johannes Lund]

This might be too late, but anyway:

> What is your evaluation of the proposal?
Unsure. For archival purposes/NSCoding replacement this seems great. As the best way to do decode JSON from external APIs I find it at least to be very unconvincing. But then, I’m not sure if this is a goal of the proposal.


> Is the problem being addressed significant enough to warrant a change to Swift?
I don’t know.


> Does this proposal fit well with the feel and direction of Swift?
To me the proposed implementation doesn’t seem particularly elegant or Swifty.

> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

(Assuming decoding JSON from external APIs is a goal)
From creating and maintaining the Decodable <https://github.com/Anviking/Decodable> library I learned:
- There are lots of weird APIs out there, that ultimately should be simple to support (e.g how optional values are described, bools as strings, 1-length arrays represented without the wrapping array, etc, etc). This proposal doesn’t talk about these kinds of problems (I don’t even see an optional property in an example), and I haven’t been able to get a sense of whether they are solvable or not with the proposed implementation, which I do not fully understand.
- Good error messages (with like backtraces) are important when writing lots of of decoding code by hand. I see no mentions of error messages in these proposals. Swift-Error breakpoints, could be a solution, but from my experience it’s not really feasible.


> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Several quick readings and quite a bit of thinking. I am really confused by these proposals though.

Johannes Lund
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170413/b77d3dac/attachment.html>