<div dir="ltr">Can you ping the list when aspects of this work lands in master? I have real world code that I want to see how this new stuff shakes out when attempting to use.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 26, 2017 at 9:24 AM Tony Parker via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi Riley,<br><div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div>On Apr 25, 2017, at 6:11 PM, Riley Testut via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_-2674425030077598804Apple-interchange-newline"><div><div style="word-wrap:break-word"><div>I’m sure this has already been discussed, but why are the methods throwing NSErrors and not Enums? If I’m remembering correctly, the original reason for this was because this was meant to be a part of Foundation. Now that this is in the Standard Library, however, it seems strange that we’re still using NSError.</div><div><br></div><div>Second question that again I’m sure was asked and answered already, but: why do we require implementations for each concrete numeric type (Int, Int8, Int16, Float, etc), instead of using protocols (such as the new Integer protocols)?</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div>To answer your second question, the reason is that using the protocol implies that all encoders and decoders must support anything that conforms to that protocol. We’re not sure this is a reasonable requirement. Many formats do not have any kind of support for arbitrary size integers, for example. Therefore, we felt it was best to limit it to a set of concrete types.</div><div><br></div><div>We could change our minds on this before we ship Swift 4, if we feel it was the wrong decision. Now that the proposals are accepted we will be landing these branches in master soon, which means everyone has a great chance to try it out and see how it feels in real world usage before it’s final.</div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>- Tony</div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Apr 25, 2017, at 3:59 PM, Douglas Gregor via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_-2674425030077598804Apple-interchange-newline"><div><div style="word-wrap:break-word">Proposal Link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md</a><div><br></div><div>Hello Swift Community,</div><div><br></div><div>The review of SE-0166 “Swift Archival &amp; Serialization” ran from April 6...12, 2017. The proposal is <b>accepted</b> with some minor modifications. Specifically, the core protocols and types will be sunk down into the Swift standard library for more tight integration with the Swift language and compiler, and the operations specifically involving Foundation’s “Data” type will be removed. The proposal document has been updated with more detail. Thank you everyone for participating in this review!</div><div><br></div><div><span class="m_-2674425030077598804Apple-tab-span" style="white-space:pre-wrap">        </span>- Doug</div><div><span class="m_-2674425030077598804Apple-tab-span" style="white-space:pre-wrap">        </span>Review Manager</div><div><br></div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>