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
