[swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

[Tony Parker]

Hi Florent,

We definitely thought about this while designing the set of types with the Codable proposals.

One serious concern was just how much API surface area there already is with Codable. If we open up the internal classes as well, we risk confusing the majority of people who are just adopting Codable with APIs that are intended only for the minority of people who are trying to create their own custom encoders and decoders.

Any thoughts on how to mitigate this?

- Tony

> On Nov 3, 2017, at 9:58 AM, Florent Vilmart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> The pitch:
> 
> - Keep JSONEncoder / JSONDecoder as 'proxies' to encoding to Data
> - Make _JSONEncoder / _JSONDecoder open classes
> - Mark public all container implementations of UnkeyedEncodingContainers etc... 
> - Find a good naming for the _JSONEncoder and _JSONDecoder, that doesn't conflict with JSONEncoder / JSONDecoder but also denotes they conform to Encoder. 
> 
> 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.
>  
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171106/b755ba09/attachment.html>