<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Reply-all this time too. :)<div class=""><div style="font-family: sans-serif;" class=""><p dir="auto" class="">Thanks for the feedback, David!</p><p dir="auto" class=""><code bgcolor="#F7F7F7" style="background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; margin: 0px; padding: 0px 0.4em;" class="">encodeIfPresent</code> and <code bgcolor="#F7F7F7" style="background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; margin: 0px; padding: 0px 0.4em;" class="">decodeIfPresent</code> are not strictly necessary, but they’re useful for further cutting down boilerplate. <code bgcolor="#F7F7F7" style="background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; margin: 0px; padding: 0px 0.4em;" class="">encodeIfPresent</code> is equivalent to</p><pre bgcolor="#F7F7F7" style="background-color: rgb(247, 247, 247); border-top-left-radius: 5px; border-top-right-radius: 5px; border-bottom-right-radius: 5px; border-bottom-left-radius: 5px; margin-left: 15px; margin-right: 15px; max-width: 90vw; overflow-x: auto; padding: 5px;" class=""><code bgcolor="#F7F7F7" style="border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; margin: 0px; padding: 0px;" class=""><span style="color: rgb(0, 136, 0); font-weight: bold;" class="">if</span> <span style="color: rgb(0, 136, 0); font-weight: bold;" class="">let</span> <span style="color: rgb(153, 102, 51);" class="">value</span> = value {
try container.encode(value, forKey: .someKey)
}
</code></pre><p dir="auto" class="">and <code bgcolor="#F7F7F7" style="background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; margin: 0px; padding: 0px 0.4em;" class="">decodeIfPresent</code> is equivalent to</p><pre bgcolor="#F7F7F7" style="background-color: rgb(247, 247, 247); border-top-left-radius: 5px; border-top-right-radius: 5px; border-bottom-right-radius: 5px; border-bottom-left-radius: 5px; margin-left: 15px; margin-right: 15px; max-width: 90vw; overflow-x: auto; padding: 5px;" class=""><code bgcolor="#F7F7F7" style="border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; margin: 0px; padding: 0px;" class=""><span style="color: rgb(0, 136, 0); font-weight: bold;" class="">if</span> container.<span style="color: rgb(0, 112, 32);" class="">contains</span>(.someKey) {
value = try container.decode(Value.<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">self</span>, forKey: .someKey)
} <span style="color: rgb(0, 136, 0); font-weight: bold;" class="">else</span> {
value = <span style="color: rgb(0, 136, 0); font-weight: bold;" class="">nil</span>
}
</code></pre><p dir="auto" class="">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 <code bgcolor="#F7F7F7" style="background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; margin: 0px; padding: 0px 0.4em;" class="">Optional</code> wrapping/unwrapping:</p><pre bgcolor="#F7F7F7" style="background-color: rgb(247, 247, 247); border-top-left-radius: 5px; border-top-right-radius: 5px; border-bottom-right-radius: 5px; border-bottom-left-radius: 5px; margin-left: 15px; margin-right: 15px; max-width: 90vw; overflow-x: auto; padding: 5px;" class=""><code bgcolor="#F7F7F7" style="border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; margin: 0px; padding: 0px;" class=""><span style="color: rgb(0, 136, 0); font-weight: bold;" class="">func</span> <span style="color: rgb(0, 102, 187); font-weight: bold;" class="">init</span>(from decoder: Decoder) throws {
<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">let</span> <span style="color: rgb(153, 102, 51);" class="">container</span> = try decoder.container(keyedBy: CodingKeys.<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">self</span>)
<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">if</span> container.<span style="color: rgb(0, 112, 32);" class="">contains</span>(.prop1) {
prop1 = try container.decode(Prop1Type.<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">self</span>, forKey: .prop1)
} <span style="color: rgb(0, 136, 0); font-weight: bold;" class="">else</span> {
prop1 = <span style="color: rgb(0, 136, 0); font-weight: bold;" class="">nil</span>
}
<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">if</span> container.<span style="color: rgb(0, 112, 32);" class="">contains</span>(.prop2) {
prop2 = try container.decode(Prop2Type.<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">self</span>, forKey: .prop2)
} <span style="color: rgb(0, 136, 0); font-weight: bold;" class="">else</span> {
prop2 = <span style="color: rgb(0, 136, 0); font-weight: bold;" class="">nil</span>
}
<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">if</span> container.<span style="color: rgb(0, 112, 32);" class="">contains</span>(.prop3) {
prop3 = try container.decode(Prop3Type.<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">self</span>, forKey: .prop3)
} <span style="color: rgb(0, 136, 0); font-weight: bold;" class="">else</span> {
prop3 = <span style="color: rgb(0, 136, 0); font-weight: bold;" class="">nil</span>
}
}
<span style="color: rgb(136, 136, 136);" class="">// vs.</span>
<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">func</span> <span style="color: rgb(0, 102, 187); font-weight: bold;" class="">init</span>(from decoder: Decoder) throws {
<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">let</span> <span style="color: rgb(153, 102, 51);" class="">container</span> = try decoder.container(keyedBy: CodingKeys.<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">self</span>)
prop1 = try container.decodeIfPresent(Prop1Type.<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">self</span>, forKey: .prop1)
prop2 = try container.decodeIfPresent(Prop2Type.<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">self</span>, forKey: .prop2)
prop3 = try container.decodeIfPresent(Prop3Type.<span style="color: rgb(0, 136, 0); font-weight: bold;" class="">self</span>, forKey: .prop3)
}</code></pre><p dir="auto" class="">On 23 Jun 2017, at 13:52, David Hart wrote:</p></div><div style="font-family: sans-serif;" class=""></div><blockquote style="font-family: sans-serif; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(119, 119, 119); color: rgb(119, 119, 119); margin: 0px 0px 5px; padding-left: 5px;" class=""><div id="69D5C304-A498-4489-AF6C-11E4EADF2854" class=""><div dir="auto" class=""><div class="">There are a lot of great changes here which make sense after the fact. I'll try to play around with them.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class="">On 23 Jun 2017, at 21:47, Itai Ferber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><p dir="auto" class="">Hi swift-evolution,</p><p dir="auto" class="">Over the course of the past few weeks, we’ve been gathering feedback about the outcome of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md" style="color: rgb(57, 131, 196);" class="">SE-0166</a> and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md" style="color: rgb(57, 131, 196);" class="">SE-0167</a> (both internally and externally), and we gathered a collection of updates that we’re going to introduce to the proposals and to the implementation.</p><p dir="auto" class="">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.</p><p dir="auto" class="">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.</p><p dir="auto" class="">Thanks for all of your feedback!</p><p dir="auto" class="">— Itai</p></blockquote><blockquote type="cite" class=""><swift-archival-serialization-updates.html></blockquote><blockquote type="cite" class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></div></div></blockquote><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 24, 2017, at 1:29 AM, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Sending out again to the whole mailing list ;-)</div><div class=""><br class=""></div><div class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">There are a lot of great changes here which make sense after the fact. I'll try to play around with them.</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">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?</span></div></div><div class=""><br class="">On 23 Jun 2017, at 21:47, Itai Ferber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8" class="">
<div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">Hi swift-evolution,</p><p dir="auto" class="">Over the course of the past few weeks, we’ve been gathering feedback about the outcome of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md" style="color:#3983C4" class="">SE-0166</a> and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md" style="color:#3983C4" class="">SE-0167</a> (both internally and externally), and we gathered a collection of updates that we’re going to introduce to the proposals and to the implementation.</p><p dir="auto" class="">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.</p><p dir="auto" class="">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.</p><p dir="auto" class="">Thanks for all of your feedback!</p><p dir="auto" class="">— Itai</p>
</div>
</div>
</div></blockquote><blockquote type="cite" class=""><div class=""><swift-archival-serialization-updates.html></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></body></html>