<!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 Jon,</p>
<p dir="auto">This was a conscious choice in the API design, for three main reasons:</p>
<ol>
<li value="1">There is a big difference between the API surface exposed at the top-level for encoding and decoding and the middle levels. A method like <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">decode(_ type: T, from data: Data)</code> is really only appropriate at the top level of a given decoder, and likewise, exposing individual encoding and decoding containers is really only appropriate at the middle levels. We intentionally left these APIs separate to avoid exposing methods in inappropriate places (so the <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Decoder</code> protocol doesn’t expose the top-level method)</li>
<li value="2">Among top-level interfaces, there is variability in what different decoders can expose. <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">JSONDecoder</code>, for instance, exposes only a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">decode(_ type: T, from data: Data)</code> method, while <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">PropertyListDecoder</code> has another method which also exposes the <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">PropertyListSerialization.PropertyListFormat</code> of the decoded data, which would not be appropriate to expose on <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">JSONDecoder</code>. In the future, these two might diverge further if we decide to specify the API even further, but more importantly, other decoders might find a different top-level API to be more appropriate than these methods (e.g. a format which only allows top-level dictionaries might want to expose only a decode method which accepts a dictionary type)</li>
<li value="3">Given that, we found that it would be too confusing to expose top-level encoders and decoders as a separate type from <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Encoder</code>/<code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Decoder</code> for not much benefit</li>
</ol>
<p dir="auto">If you find the concept useful for your own work and are willing to sacrifice some portability, you can always define a protocol with the interface appropriate for your project and have these decoders conform to that protocol.</p>
<p dir="auto">— Itai</p>
<p dir="auto">On 2 Sep 2017, at 18:47, Jon Shier via swift-users wrote:</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">Swift Users:<br>
I’ve been exploring the creation of Decodable response serializers for Alamofire. However, there doesn’t actually seem to be any way to express the notion of a generic decoder. The Decoder protocol itself doesn’t require a `decode(type:from:)` method, and neither JSONDecoder or PropertyListDecoder conform to Decoder in the first place. Were these facts conscious choices or oversights? It certainly seems very useful to be able to treat decoders generically.<br>
<br>
<br>
<br>
Jon Shier<br>
_______________________________________________<br>
swift-users mailing list<br>
swift-users@swift.org<br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" style="color:#777">https://lists.swift.org/mailman/listinfo/swift-users</a></p>
</blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>