[swift-evolution] [Update] Updates to SE-0166 and SE-0167

[Itai Ferber]

Reply-all this time too. :)
Thanks for the feedback, David!

encodeIfPresent and decodeIfPresent are not strictly necessary, but they’re useful for further cutting down boilerplate. encodeIfPresent is equivalent to

if let value = value {
    try container.encode(value, forKey: .someKey)
}
and decodeIfPresent is equivalent to

if container.contains(.someKey) {
    value = try container.decode(Value.self, forKey: .someKey)
} else {
    value = nil
}
They’re not big, but when you have a long list of optional properties, it’s much easier to read and comprehend than staring at a wall of Optional wrapping/unwrapping:

func init(from decoder: Decoder) throws {
    let container = try decoder.container(keyedBy: CodingKeys.self)

    if container.contains(.prop1) {
        prop1 = try container.decode(Prop1Type.self, forKey: .prop1)
    } else {
        prop1 = nil
    }

    if container.contains(.prop2) {
        prop2 = try container.decode(Prop2Type.self, forKey: .prop2)
    } else {
        prop2 = nil
    }

    if container.contains(.prop3) {
        prop3 = try container.decode(Prop3Type.self, forKey: .prop3)
    } else {
        prop3 = nil
    }
}

// vs.

func init(from decoder: Decoder) throws {
    let container = try decoder.container(keyedBy: CodingKeys.self)
    prop1 = try container.decodeIfPresent(Prop1Type.self, forKey: .prop1)
    prop2 = try container.decodeIfPresent(Prop2Type.self, forKey: .prop2)
    prop3 = try container.decodeIfPresent(Prop3Type.self, forKey: .prop3)
}
On 23 Jun 2017, at 13:52, David Hart wrote:

There are a lot of great changes here which make sense after the fact. I'll try to play around with them.

One thing I'm concerned about: with the new Optional conformance, why do we still need decodeIfPresent and encodeIfPresent? They seem superfluous now, and potentially confusing. Should users call encodeIfPresent/decodeIfPresent or encode/decode with an optional type? Do the have the same semantics?

On 23 Jun 2017, at 21:47, Itai Ferber via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:

> Hi swift-evolution,
> 
> Over the course of the past few weeks, we’ve been gathering feedback about the outcome of SE-0166 <https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md> and SE-0167 <https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md> (both internally and externally), and we gathered a collection of updates that we’re going to introduce to the proposals and to the implementation.
> 
> Attached is rendered HTML (I don’t want to make your mail clients unusable like last time!) that lays out what we’d like to do. We’re not looking to do a full review of these changes, but if you have feedback or questions, we’re happy to get responses here.
> 
> Please note that some of these features have already been implemented (the new error types, some of the optionality changes, collection conformances, etc.), but we are receptive to comments on all of it. The existing proposals will also be updated to incorporate these updates.
> 
> Thanks for all of your feedback!
> 
> — Itai
> 
> <swift-archival-serialization-updates.html>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

> On Jun 24, 2017, at 1:29 AM, David Hart <david at hartbit.com> wrote:
> 
> Sending out again to the whole mailing list ;-)
> 
> There are a lot of great changes here which make sense after the fact. I'll try to play around with them.
> 
> One thing I'm concerned about: with the new Optional conformance, why do we still need decodeIfPresent and encodeIfPresent? They seem superfluous now, and potentially confusing. Should users call encodeIfPresent/decodeIfPresent or encode/decode with an optional type? Do the have the same semantics?
> 
> On 23 Jun 2017, at 21:47, Itai Ferber via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> Hi swift-evolution,
>> 
>> Over the course of the past few weeks, we’ve been gathering feedback about the outcome of SE-0166 <https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md> and SE-0167 <https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md> (both internally and externally), and we gathered a collection of updates that we’re going to introduce to the proposals and to the implementation.
>> 
>> Attached is rendered HTML (I don’t want to make your mail clients unusable like last time!) that lays out what we’d like to do. We’re not looking to do a full review of these changes, but if you have feedback or questions, we’re happy to get responses here.
>> 
>> Please note that some of these features have already been implemented (the new error types, some of the optionality changes, collection conformances, etc.), but we are receptive to comments on all of it. The existing proposals will also be updated to incorporate these updates.
>> 
>> Thanks for all of your feedback!
>> 
>> — Itai
>> 
>> <swift-archival-serialization-updates.html>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

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