<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi swift-evolution,</div><div class=""><br class=""></div><div class="">I have a few feedbacks on SE-0166 and SE-0167. I’m a library maintainer of a Swift library for my company. We’re a payment gateway service and have a wide range of support library in many programming languages (including Swift).</div><div class=""><br class=""></div><div class="">Here’re my feedbacks</div><div class=""><br class=""></div><div class="">1. The auto synthesized code from the Swift compiler is a great feature but I’m not sure if this is a bug. If I have a property of type Dictionary<String, Any>, the auto synthesize doesn’t work and I need to implement the init(from decoder:) method manually (with code like `metadata = try container.decodeIfPresent([String: Any].self, forKey: .metadata)`) I will report this as a bug on <a href="http://bugs.swift.org" class="">bugs.swift.org</a></div><div class="">2. In JSONEncoder/Decoder, you can specify the date parsing behavior since there’re many ways to represent this. My thought is that that should apply to `DateComponents` too since there are also many ways to represent `DateComponent` e.g. the ISO8601 also has a spec for parsing the date or time which should map to `DateComponents` type in Swift. And since the DateComponents already conforms to the Decodable protocol so I cannot (and should not) override the system behavior so I need to do the decoding manually on every types that have a property of DateComponents type</div><div class="">3. Since Swift has an associated value enum while many others doesn’t have (including JavaScript which is the mother of JSON), I design our library to use the power of associated value enum as much as possible. This means that there are some types/properties those are built from a multiple properties of a JSON object.</div><div class="">For example: The status property of Charge is an enum which has a associated value case for `failure` status. So in my library it is built from the `status` and `failureMessage` properties in JSON. For now there is no simple or automatic way (auto synthesized code from Swift Compiler) to do this in Decodable. I need to implement it manually on every types those have this similar properties. And TBH I still don’t have any ideas on how to design the Decodable to support this feature.</div><div class=""><br class=""></div><div class="">Those are my feedbacks on SE-0166 and SE-0167 for now. I hope my feedbacks would help the Swift and Swift community</div><div class=""><br class=""></div><div class="">Best regards,</div><div class="">Pitiphong Phongpattranont</div><div class=""><br class=""></div>
> Hi swift-evolution,<br class="">> <br class="">> Over the course of the past few weeks, we’ve been gathering feedback<br class="">> about the outcome of<br class="">> [SE-0166](<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md</a>)<br class="">> and<br class="">> [SE-0167](<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md</a>)<br class="">> (both internally and externally), and we gathered a collection of<br class="">> updates that we’re going to introduce to the proposals and to the<br class="">> implementation.<br class="">> <br class="">> Attached is rendered HTML (I don’t want to make your mail clients<br class="">> unusable like last time!) that lays out what we’d like to do. We’re<br class="">> not looking to do a full review of these changes, but if you have<br class="">> feedback or questions, we’re happy to get responses here.<br class="">> <br class="">> Please note that some of these features have already been implemented<br class="">> (the new error types, some of the optionality changes, collection<br class="">> conformances, etc.), but we are receptive to comments on all of it. The<br class="">> existing proposals will also be updated to incorporate these updates.<br class="">> <br class="">> Thanks for all of your feedback!<br class="">> <br class="">> — Itai<br class="">> <br class="">> <br class="">><span class="Apple-converted-space"> </span>
</body></html>