> On 12 Apr 2017, at 20:44, Russ Bishop via swift-evolution
> <[email protected]> wrote:
>
>
>> On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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
>>
>> <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
>> <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
>>
>> <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?
> It is a good first step but I feel like it tries to match NSSecureCoding
> design patterns too strongly and introduces a lot of potential for API misuse
> (convention rather than using the type system to our advantage). If we ask
> "what does a modern take on NSSecureCoding look like?", this proposal is the
> answer. If we ask "how can we do better than NSSecureCoding?" then this
> proposal needs a little bit of refinement.
I also agree that the API feels slightly more influenced by NSCoding and
Objective-C paradigms than by Swift idioms.
> Some examples:
>
> * String and Int keys being optional, giving a CodingKey the opportunity to
> return nil for both at runtime.
> * Encoder has three functions, but only one may ever be called. This API is
> the opposite of "pit of success”.
The amount of preconditions in the documentation of Coder and then
CocoaError.coderTypeMismatch errors of Decoder paint the same picture. I
understand the argument that writing this proposal taking full advantage of the
type system would exponentially increase the number of types and worsen the
API. But perhaps the Encoder/Decoder protocols could take advantage of more
types.
> There is also the problem of an implementation cliff: A type that has one
> non-Encodable property suddenly needs to provide a complete implementation.
> It is relatively common to have ephemeral data you don't even want to be
> encoded but again it seems like you need to jump immediately to a completely
> manual solution.
I don’t think you’re right here. The proposal states:
• Types falling into (1) — and types which manually provide a CodingKey
enum (named CodingKeys, directly, or via a typealias) whose cases map 1-to-1 to
Encodable/Decodable properties by name — get automatic synthesis of init(from:)
and encode(to:) as appropriate, using those properties and keys
So if you do have ephemeral data, you’d only need to define the CodingKey enum
and be good to go.
> There may not be a way to square this circle but it is worth thinking about.
> One improvement would be that a type can provide its own CodingKey but still
> get automatic conformance for all properties that match. At least then you
> would have a way to filter out the properties you don't want.
>
>
> I don't understand why KeyedEncodingContainer needs all those overloads;
> automatic conformance to Encodable should be provided for the stdlib types in
> those overloads so why would they be necessary?
I’ve been beating the same bush. I know the arguments but it just feels wrong
to me. That’s a case where this API definitely feels more like Objective-C than
Swift.
> KeyedEncodingContainer.encodeWeak seems like it should be a protocol
> refinement so you can check for the capability (or potentially know at
> compile time). The decoder begs a similar question: why not rely on the
> generic functions? (One minor bit of bike shedding: decode/decodeIfPresent
> could instead be decode(required:) and decode(optional:)).
>
>
> I really strongly dislike mixing up the Unkeyed and Keyed concepts. A type
> should need to explicitly opt-in to supporting unkeyed and that should be
> enforced at compile time. Unkeyed encoding is a potential versioning
> nightmare and should be handled with care.
>
>
>> Is the problem being addressed significant enough to warrant a change to
>> Swift?
> Definitely yes.
>
>> Does this proposal fit well with the feel and direction of Swift?
> See comments above
>
>> If you have used other languages or libraries with a similar feature, how do
>> you feel that this proposal compares to those?
> Yes; C#'s serialization attributes are a better and more comprehensive
> solution but we don't have custom attributes in Swift and property behaviors
> were deferred. This problem is too important to leave to the future though.
> If we did ever add custom attributes or if property behaviors get implemented
> then this design could adopt them incrementally without breaking
> compatibility (e.g. a serialization transformer behavior that turns a
> non-Encodable property into an Encodable one, or a behavior that ignores a
> property for serialization purposes).
>
>
>
> I want to say thank-you to Itai, Michael, and Tony for their hard work on
> this and the related proposal; having done a proposal myself I know how much
> work it entails.
>
>
> Russ Bishop
>
>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
