<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;">
<div>At Swift Summit, we discussed with Joe and Jordan about opening up the Encoder/Decoder classes in order to make the work of an encoder designer easier.</div>
<div><br /></div>
<div>As I was working on an API project, I found myself into the situation of needing to tweak so slightly the encoding strategy this required a full copy/paste of the JSONEncoder.swift file and playing with the internals. I also wanted to implement a simple QueryStringEncoder/Decoder that would properly encode / decode a query string.</div>
<div><br /></div>
<div>The internally defined classes are proven a very powerful tool of reflection as well, being able to collect / untransform a series of containers safely into a strongly typed swift object.</div>
<div><br /></div>
<div>The pitch:</div>
<div><br /></div>
<div>- Keep JSONEncoder / JSONDecoder as 'proxies' to encoding to Data</div>
<div>- Make _JSONEncoder / _JSONDecoder open classes</div>
<div>- Mark public all container implementations of UnkeyedEncodingContainers etc... </div>
<div>- Find a good naming for the _JSONEncoder and _JSONDecoder, that doesn't conflict with JSONEncoder / JSONDecoder but also denotes they conform to Encoder. </div>
<div><br /></div>
<div>Opening those API's isn't for the general Codable implementation, the JSONEncoder/JSONDecoder should stay as-is but it's intended to reduce the amount of boiler plate one would need to implement in order to provide different serialization mechanism / strategy.</div>
<div> </div>
</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br />
<div></div>
</div>
</body>
</html>