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

[Brent Royal-Gordon]

> On Apr 6, 2017, at 11:10 AM, Douglas Gregor <dgregor at apple.com> wrote:
> 
> 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>

> What is your evaluation of the proposal?
I've interrogated this proposal pretty thoroughly in the draft threads, and overall, I'd say it's excellent. I don't agree with every decision, but I think they are all very defensible.

If there is one thing I'm still not satisfied with, it's the large number of overloaded `encode` and `decode` methods; I think this design puts far too much effort into optimizing performance for rarely used types like `UInt16` when it would be better to write smaller, more compact interfaces that are easier to wrap your head around.

I'm also not too happy with the use of `mutating` on the containers. Some containers require mutability, others don't, it's impossible to remember which ones are which, and Swift will complain about you using `var` instead of `let` or vice versa if you get it wrong.

But these are minor nitpicks. This proposal will be a huge boon to Swift development and I support it wholeheartedly.

Incidentally, I think that in the future, we should try to infuse elements of alternative design 5 (where containers are scoped by closures). This points the way to a feature we ought to add to Swift: An `@once` annotation which promises that a closure parameter is executed exactly once, and (if the closure is not `@escaping`) can therefore be trusted by the definite initialization checker. We can then introduce closure-based versions of the container-fetching methods and have a nice, backwards-compatible improvement in ergonomics.

> Is the problem being addressed significant enough to warrant a change to Swift?
Absolutely. The lack of a good serialization solution is a major issue.

> Does this proposal fit well with the feel and direction of Swift?
Mostly. There are things that don't, like the large and arbitrary set of primitive types and the treatment of Optionals, but I think these design decisions are defensible.

> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I think this is a much better design than NSCoding in many ways.

> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I think it's fair to say: A lot.

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170410/7b098da2/attachment.html>