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

[Karl Wagner]

> 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?
-1

The proposal is mis-named; it isn’t Swift Archival and Serialisation. What it really is, is Foundation Archival and Serialisation. The proposal doesn’t even mention where these new protocols and types will live, but the general talk is all about Foundation and nothing at all about the standard library, so I’m assuming that’s where they will go.

- I fundamentally disagree with having the conformance be synthesised. We don’t do this anywhere else in the language, AFAIK. I believe it will make it easier for naive developers to suffer privacy leaks, or cause hard-to-debug crashes because they were persisting and restoring non-persistable values.

- I believe the proposal is premature. It is likely that Smart KeyPaths would allow us to define a collection of serialisable details of an instance in a convenient way which does not require compiler magic. Such a design could also allow more features than the one proposed (KeyPaths can select particular details from deep within properties, and the “collection" could be a Dictionary of KeyPaths to Serialisation Keys). A lot of effort has been made to make this all “magic” and automatic, but I see that as an anti-goal. I believe we are close to being able to write a safe, convenient serialisation API without the need for hidden and un-debuggable synthesis. This proposal should wait.

- Not only that, but I feel it would muddy the line between the Swift language and Foundation beyond what is acceptable. Those libraries are crucial to Apple’s platforms, so it’s understandable that you’re so protective of them, but I personally feel they are very far from what the “core libraries” of Swift could be. For example, having separate Data and DispatchData types, and no owned reference-counted buffer in the standard library at all is a horrible design IMO. Even minor pull-requests in to the core libraries seems to require herculean amounts of effort (https://github.com/apple/swift-corelibs-libdispatch/pull/172 https://github.com/apple/swift/pull/7446), so I have precisely 0 hope of anybody outside of Apple bringing any fresh ideas or improvements to the table.

I don’t want to go too much in to my gripes with Foundation and Dispatch, but suffice to say that giving them special language consideration is a step too far. This is Apple proposing a design that’s good for Apple and nobody else, and I’m not in favour of breaking layering even further to accomplish it.

> Is the problem being addressed significant enough to warrant a change to Swift?
No. I feel the solution is disproportionate to the problem.

> Does this proposal fit well with the feel and direction of Swift?
It’s a poor design, only differing from existing libraries in how Apple-specific it is, and the principle-breaking language magic needed in order to achieve it. It does not fit at all with much better proposals, like Smart KeyPaths. Maybe the authors should have co-ordinated more with others before proposing it. And presenting an implementation PR at the same time just feels wrong IMO, like Apple expects to have this proposal rubber-stamped for their SDK plans.

> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I also develop for Android, and it’s extremely easy to implement serialisation using annotation-based libraries such as Icepick (https://github.com/frankiesardo/icepick).
I even feel like that is too much magic sometimes, but I’d prefer an annotation-based solution to invisible conformance synthesis any day of the week.

> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read the previous discussions, and have read and re-read the proposal a couple of times.


> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> _______________________________________________
> 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/20170413/e9def2c8/attachment.html>