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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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 <da...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution