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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
