<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Hi Slava,</p>
<p dir="auto">Thanks for your comments!</p>
<p dir="auto">On 16 Mar 2017, at 13:50, Slava Pestov wrote:</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Hi Itai,<br>
<br>
I’m wondering what the motivation is for keeping this as part of Foundation and not the standard library. It seems like you’re landing an implementation of this in the Foundation overlay on master, and another copy of all the code will have to go into swift-corelibs-foundation. This seems suboptimal. Or are there future plans to unify the Foundation overlay with corelibs-foundation somehow?</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">This has to be part of Foundation because <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Data</code>, a Foundation type, is one of the primitive types of serialization. This will be doubly true if we decide to add <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Date</code> as another primitive type.</p>
<p dir="auto">I agree that this is suboptimal at the moment, but we will work to find a way to keep the work in sync in a reasonable manner.</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Also the implementation uses some Foundation-isms (NSMutableArray, NSNumber) and it would be nice to stick with idiomatic Swift as much as possible instead.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Using the Foundation framework is just as idiomatic in Swift… ;)<br>
In this specific case, we need collections with reference semantics (<code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NSMutableArray</code> and <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NSMutableDictionary</code>) and a concrete type-erased number box (<code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NSNumber</code>); theres’s no reason to reinvent the wheel if we already have exactly the tools we need.</p>
<p dir="auto">The reference implementation at the moment goes through <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">JSONSerialization</code>, which affects the specifics of its implementation. This may change in the future.</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Finally you should take a look at the integer protocol work (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md" style="color:#777">https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md</a> <<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md" style="color:#777">https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md</a>>) to replace the repetitive code surrounding primitive types, however I don’t know if this has landed in master yet.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">As mentioned in other emails, the list of primitive types was carefully chosen because we need to have a concrete list of types which consumers can rely on being supported, and that <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Encoder</code>s and <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Decoder</code>s know they <em>must</em> support.</p>
<p dir="auto">Specifically:</p>
<ol>
<li value="1">For binary formats, the difference between an <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Int16</code> and an <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Int64</code> is significant. The <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Encoder</code> would need to know that it’s received one type or another, not just a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">FixedWidthInteger</code>; this would involve a runtime check of the concrete type of the argument</li>
<li value="2">Any type can conform to these protocols — nothing is preventing me from writing an <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Int37</code> type conforming to <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">FixedWidthInteger</code> and passing it in. Most encoders would really not know what to do with this type (especially ones with binary formats), but the failure would be a runtime one instead of a static one
<ul>
<li>A concrete example of this is the <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">FloatingPoint</code> protocol. <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Float80</code> conforms to the protocol, but no common binary format I’ve seen supports 80-bit floating-point values. We’d prefer to prevent that statically by accepting only <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Float</code> and <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Double</code></li>
</ul></li>
<li value="3">Consumers of the API then have no guarantees that a specific <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Encoder</code> supports the type that they need. Did the encoder remember to support <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">UInt64</code> values? Similarly, <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Encoder</code>s and <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Decoder</code>s don’t know what types they need to be considering. Am I supposed to handle <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">UInt8</code> differently from <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Int16</code>? With a list of concrete types, this becomes immediately clear — both consumers and writers of <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Encoder</code>s have a clear contract.</li>
</ol>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Slava</p>
</blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>