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

Colin Barrett colin at springsandstruts.com
Mon Apr 10 17:17:09 CDT 2017

Proposal Link:

I'm a +1 on the proposal, I just have a few small questions and suggestions
after giving it a brief read.

1) I'm not thrilled about the name "unkeyedContainer()" and related names.
Would "sequentialContainer" or something along those lines be a better
name? The fact that it can encode several, heterogeneous values in a fixed
sequence seems to be the most salient feature of it that distinguishes it
from the keyed containers and the single value containers.

2) I feel like the reasoning behind the design for the CodingUserInfoKey
isn't clearly articulated, but it seems a bit odd to me. First off, I'm
confused why with the current design, the declaration isn't simply:

protocol CodingUserInfoKey: CodingKey, Hashable {}

I tried mocking something up with the shipping Swift 3.1, and got the
following error:

> using 'CodingUserInfoKey' as a concrete type conforming to protocol
'Hashable' is not supported

So maybe it's just a question of lack of compiler support. Still, I feel
that the lack of a connection between the CodingKey and the
CodingUserInfoKey types is fairly confusing.

To be more concrete but way more speculative, I'm assuming that current
design one is intended to declare all their keys in an enum like,

enum SomeType.Key: CodingKey {
  case foo
  case bar
  // ...
  case metaKey1
  case metaKey2

And then write an init? extension for CodingUserInfoKey.

It seems more natural however to me to leverage the nested container
support instead. What exactly that design would look like is unclear to
me—do you return a value that implements Encoder? Do you add duplicate
nestedKeyedEncoder for the userInfo case? but it seems more of a clean fit
with the rest of the API than exposing a dictionary.

Both pretty minor issues when considered with all the great ideas in the
API. Looking forward to reviewing 0167 as well!


On Thu, Apr 6, 2017 at 2:10 PM Douglas Gregor <dgregor at apple.com> 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
> 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
> 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
> 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?
>    - Is the problem being addressed significant enough to warrant a
>    change to Swift?
>    - Does this proposal fit well with the feel and direction of Swift?
>    - If you have used other languages or libraries with a similar
>    feature, how do you feel that this proposal compares to those?
>    - How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
> More information about the Swift evolution process is available at
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> -Doug
> Review Manager
> _______________________________________________
> swift-evolution-announce mailing list
> swift-evolution-announce at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170410/d1ad9904/attachment.html>

More information about the swift-evolution mailing list